A Secure Fair Exchange for SMS-Based Mobile Payment Protocols Based on Symmetric Encryption Algorithms with Formal Verification

Information security and fair exchange are essential to creating trust among all the parties participating in any sale transaction. However, implementing them in any mobile commerce is challenging due to the limitation of resources on mobile devices. Numerous m-commerce protocols that have been proposed so far still lack those two important aspects. In this paper, we propose mobile payment (m-payment) protocols, a crucial part of m-commerce, that incorporate both information security and fair exchange while retaining their own lightweight property. To allow convenience of use, the proposed protocols can be implemented on the existing Short Message Service (SMS) infrastructure. Our approach is based on the secure session key generation technique to enhance information security under lightweight conditions and involves a trusted third party to guarantee fair exchange without information disclosure. We have formally proven that our protocols are more effective and efficient than others in terms of fairness, security, and lightweight properties. In addition, the soundness and completeness of the protocols have been analyzed and proven using BAN logic and an automated security protocol proof tool named Scyther.


Introduction
Currently, mobile commerce (m-commerce) is one of the most popular methods for buying goods or services on the Internet.It has had a major impact on the growth of the world economy as well as improving the quality of life in the human society.One major factor that drives the success of m-commerce is mobile payment (m-payment), which allows the exchange of goods or services and money between a purchaser and a vendor.Therefore, m-payment is a crucial mechanism and needs to be trustworthy from the perspectives of all parties involved.There are two essential issues that can create trust in a sale transaction based on the m-payment, i.e., fair exchange and information security.These will provide all involved parties with the confidence that no one can take advantage of the others when conducting any sale transaction.In addition, they can prevent fraud.Nowadays, SMS-based transactional payments are a major model of mobile payments.This kind of payment is simple for purchasers to use.They can pay for goods or services via a plain text message sent from a mobile phone.However, the message is transmitted through the wireless network and, hence, can be eavesdropped by a malicious person.Even though the Global System for Mobile Communication (GSM) uses cryptographic techniques of A5/1 and A5/2 between the mobile device and the base station subsystem (BSS), the messages are still vulnerable [1][2][3][4].During the past few years, many researchers have investigated protocols for mobile payments with fair exchange [1,3,[5][6][7][8][9]. Unfortunately, they still lack some of the important properties of information security, e.g., mutual authentication, nonrepudiation, strong fairness (due to no involvement of a trusted third party), and undisclosed information to the trusted third party (if any).
In this paper, we review a number of existing techniques for ensuring fairness.More importantly, we propose protocols for mobile payments that satisfy the crucial properties of information security.The secure session key generation technique is employed to accomplish a security requirement.

Wireless Communications and Mobile Computing
Consequently, this results in the lightweight preservation of our protocols.Furthermore, our approach can be implemented on the current SMS infrastructure to retain its ease of use.In this method, the online TTP (trusted third party or TTP) model is chosen because the TTP is required to keep some evidences to be used when a dispute arises.Moreover, the online TTP must not be able to access or disclose information from those evidences in any case or for their own benefits.In contrast, in an offline TTP model, the information needs to be disclosed to the TTP in order to make a dispute resolution possible.
A number of mobile payment protocols have been proposed [1,3,[5][6][7][8][9]25] to secure mobile payment based on SMS text messaging.Saxena and Chaudhari [1] suggested EasySMS, which offers end-to-end secure communication through SMS between mobile users and is able to prevent several attacks, such as SMS disclosure, air modification, replay attacks, man-in-the-middle attacks, and impersonation attacks.This protocol deploys symmetric cryptography as well as hash functions.Pourali et al. [5] proposed a secure SMS model of e-commerce payment, based on Elliptic Curve Cryptography (ECC).The authors argue that their model satisfies the properties of confidentiality, integrity, authentication, and nonrepudiation.The paper provides various types of e-payment (electronic payment) business models, which are e-payment methods of mobile payment schemes.The model is suitable for SMS-based mobile payment.Kisore and Sagi [6] proposed a secure SMS protocol for a digital cash system, which is a protocol based on ECC with public key algorithms in the Cryptographic Message Syntax (CMS), key agreement protocol, and Advanced Encryption Standard (AES).The proposed digital cash system satisfied confidentiality and authentication.However, the protocols [5,6] lack bilateral authentication and some important properties of security, for example, message authentication and recipient authentication.This is because each message is encrypted with its own public key, which cannot verify the sender of the message.Bojjagani and Sastry [7] proposed SSMBP, a unique protocol for SMS which is based on mobile banking, the payment framework, and Elliptic Curve Digital Signature Algorithm (ECDSA), used for generating and verifying digital signatures and also for encryption and decryption of SMS.The Elliptic Curve Integrated Encryption Scheme (ECIES) is used to satisfy confidentiality, integrity, authentication and nonrepudiation.This protocol provides secure SMS communication between customers and banks through a mobile phone banking application and deploys both symmetric and asymmetric cryptography, including hash functions.There are five parties involved in this protocol: a payer, a payee, an issuer bank, an acquirer bank, and a payment gateway.However, the session key shared between the issuer bank and the payer (SKB), the session key shared between the issuer bank and the payment gateway (SKPG), and the session key shared between the acquirer bank and the payment gateway (SKAB) need to be transmitted over the network using static parameters that could possibly be intercepted by attackers, and the protocol is prone to brute force attacks.Rongyu et al. [8] proposed PK-SIM, a security framework, offering solutions for the development of secure mobile business applications using SMS to provide point-to-point security between the PK-SIM card and the Secure Access Gateway (SAG).There are parties involved in this protocol: a PK-SIM card for storing security credentials, a SAG for receiving and sending secure SMS messages, a trusted third party, the Certification Authority (CA) for providing a public key certification service and a mobile operator for providing the communication infrastructure for the SMS.Both symmetric and asymmetric cryptography, including hash functions, are deployed in this protocol.There are three subphases: the authentication phase, the session key establishment phase, and the communication phase.Rongyu et al. argue that their framework satisfies the requirements of authentication, integrity, and confidentiality.However, the session key UAKey (the primary key between the PK-SIM card and the SAG) needs to be transmitted over the network and, therefore, could possibly be intercepted by attackers.In other words, it is prone to brute force attacks.Saxena and Chaudhari [3] proposed SecureSMS, a new secure and optimal choice for a secure SMS messaging protocol.This protocol provides end-to-end SMS security and is able to prevent various threats and attacks such as replay attacks, man-in-the-middle attacks, SMS spoofing, and SMS disclosure.The system is based on symmetric cryptography, including the hash function.The framework satisfies authentication, confidentiality, integrity, and nonrepudiation of the messages.There are three parties involved in this protocol: The Mobile Station (MS) sends the SMS, and this is carried out by the Authentication Server (AS), with the help of the Certification Authority/Registration Authority (CA/RA).The authors argue that their protocol satisfies message mutual authentication between the MS and AS.However, within the messages, ID MS, T1, T3, and ExpT are sent in clear text and, therefore, can be easily intercepted and modified by an attacker.Minta and Panchami [9] proposed an efficient encryption protocol for securely transmitting a confidential SMS from one mobile phone to another, which serves the cryptographic goals of confidentiality, authentication, and integrity of the messages.This protocol prevents various attacks such as man-in-themiddle attack, replay attack, SMS disclosure, and over-theair modification.The protocol is composed of four parties: Mobile Station 1 (MS1), Mobile Station 2 (MS2), an Authentication Server (AS), and a Certification Authority (CA).The framework proposed by Bojjagani and Sastry [25] provides end-to-end SMS communication between the customer and the bank through a mobile application.The main objective of the framework is to design and develop a security framework for SMS banking.This framework is validated using formal methods utilizing a model-checking tool called Scyther.
Unfortunately, most of the mobile payment systems that have thus far been proposed still lack fairness.For example, some systems allow disclosure of information to the trusted third party, and some do not even involve a trusted third party.In addition, many researchers have proposed mobile payment protocols with weaknesses in some areas such as confidentiality, integrity, nonrepudiation, and mutual authentication.Mutual authentication can prevent both replay attacks and man-in-the-middle attacks, which is critical for information security.This paper introduces mobile payment protocols that enhance fairness and provide security properties such as confidentiality, integrity, nonrepudiation, and mutual authentication.In addition, the proposed protocols are lightweight and have improved security since they deploy the secure session key generation technique and the session keys will not be reused.

The Proposed Mobile Payment Protocols
In this section, we apply the fairness model in [28] to mobile payment protocols to ensure strong fairness.Later in this paper we will show that the proposed protocols satisfy strong fairness.Our protocols are composed of two subprotocols: Purchase Credit Request and Making Payment.(ii) {DK AB ,   ,   } are the key distribution parameters that are shared between the parties.Readers may find more details about the key distribution parameters from [29].Our protocols used parameters to generate the secure session key generation technique proposed in [29].
(iii)   stands for a long-term key.
(iv) DK AB stands for a distributed key.
(v)   is a random number.It is utilized to indicate the number of keys that will be produced.
(vi) SK ABj where j = 1, . .., m are the session keys shared between party  and party B.
(vii) h(M, SK ABj ) is a Message Authentication Code (MAC) of a message  and a key SK ABj .
(viii) h(M) is a hash value of a message M.
(ix) {}  is a symmetrically encrypted message of a message  with a key SK ABj .
(x) CL T is a credit limit up to which the client is allowed to purchase goods or services.
(xi) SN is a serial number for a top-up cash card purchased offline, which infers the credit limit in the client's account.
(xii) CL RM is the remaining credit in the client's account.
(xiii) OI = {, , }.TID is Transaction ID.Price is the price of goods or services, and OD is an order description containing details of the goods or services purchased.
The mobile operator establishes a Transport Layer Security (TLS) session and shares this {K OTTP , DK OTTP , m OTTP } with TTP.Both the mobile operator and TTP create a set of session keys SK OTTPj by using the secure session key generation technique proposed in [29], where j = 1, . .., m, while implementing the system.The proposed protocols assume that the session keys between parties are the same.

The Fairness Model for Internet
Transactions.Thammarat et al. [28] proposed a fairness model for Internet transactions.The model supports a mobile payment protocol.This model still lacks some of the conditions to fully ensure fairness.Therefore, we extend the proposed model in [28] to complete the fairness protocols.The symbolic notations and modal operators can be defined as follows.
Let  denote a payment system defined as S = {, , }, where  is a client who buys goods or services, M is a merchant, and PG is a payment gateway which acts as the financial institution for both  and .In the payment system, C acts as the payer and  acts as the payee.In addition, let  be a verifier, an external party not involved in a transaction but trusted by all parties, and let TTP denote a trusted third party.TTP is not involved in the transaction itself but keeps all transaction data for later verification.R denotes any party.
(i) P authorized X: the party  has authorization to perform an action X.
(ii) P CanProve X to R: the party  is able to prove to the party  that the statement  is true without revealing any information which is considered to be secret to R.
(iii) Payment-order(C, M) is the interaction between the client and the merchant when the client requests to purchase goods or services from the merchant.
(iv) Debit(C, PG) is the interaction between the payment gateway and the client regarding the deduction of the payment token, requested by the client, from the client's account.
(v) Credit(M, PG) is the interaction between the payment gateway and the merchant in order to transfer the payment token to the merchant account.
(vi) Log(C, TTP) is the interaction between TTP and the client, enabling TTP to keep all the transactions occurring between the client and related parties and send them to the client.
We define a new operator called "satisfies", which refers to the situation where a party satisfies the result given at the end of the transaction.For example, "C satisfies payment-order(C, M)" means that the client  has satisfied the results of the transaction occurring between the client and the merchant.The conditions of fairness are as follows: Strong fairness: (1) TTP is involved.(2) There is no information disclosure to TTP.Weak fairness: (1) TTP is involved.(2) There is information disclosure to TTP.No fairness: (1) TTP is not involved.The details of each condition of fairness can be explained as follows: (i) TTP is involved: TTP keeps all the transactions and provides the transaction occurring between the parties as evidence when a dispute arises.
(ii) TTP is not involved: there is no TTP to keep all transactions and no evidence can be sent to the parties.When a dispute arises, parties cannot have dispute resolution.It is not possible to ensure fairness that is not strongly an involvement of TTP [21,30].
(iii) Information disclosure to TTP: TTP can read all transactions occurring between the two parties.TTP may sell the information about parties to the competitors.
(iv) No information disclosure to TTP: there is no TTP involved.TTP cannot read all transactions occurring between parties and therefore cannot sell the information about parties to the competitors.
Table 1 shows the advantages and disadvantages of the types of fairness.Strong fairness has more advantages than the other types, for example, semi-TTP (semitrusted third party), and it does not need a reliable network.In this paper, we will apply Thammarat's fairness model for Internet transactions to existing SMS mobile payment protocols for strong fairness.Note that a semi-TTP is one that can misbehave on its own but will not collude with any of the participating parties.
Client's Fairness.The following requirements must be satisfied from the client's point of view to achieve the goal of fairness: In each client's opinion, the client will satisfy the transactions only if he/she gets both a payment-order response from the merchant and a debit response from the payment gateway.However, the responses must be from the previous transaction made by the client.All requests are sent to the trusted third party.
Merchant's Fairness.For a transaction to be satisfactory in the merchant's opinion, the following requirements must be satisfied: It can be seen from the above statements that the merchant will satisfy a transaction if he/she has delivered or committed to deliver goods or services to clients as a result of receiving a payment-order request from the client.The payment has to be processed by the payment gateway.The payment gateway must transfer the amount requested by the merchant to the account of the merchant, prior to the delivery of goods or services to the client.Payment Gateway's Fairness.For a transaction to be satisfactory in the payment gateway's opinion, the following requirements must be satisfied: PG It can be seen that the payment gateway will satisfy a transaction if the payment gateway has performed paymentclearing as a result of the requests from the client and merchant.Specifically, the payment gateway must perform actions according to the debit and credit requests made by both the client and the merchant.The payment gateway transfers or commits to deduct the amount requested by the client and transfer the amount requested by the merchant to the account of the merchant.

Background Concept on the Secure Session Key Generation
Technique.In this section, we will explain the concept of the secure session key generation technique that is used in a phase of our proposed protocols.The topics that are extensively discussed in symmetric encryptions are the secure session key generation techniques.Many researchers have presented a secure session key generation technique used in their own Session key ３＋ Ｄ , Ｄ = 1, . .., -

Intermediate key generation
Round n

Intermediate key generation Round 1
Preference key generation Figure 1: Session key generator.
papers [29,[31][32][33][34][35].Among all the mentioned approaches, [29] proposed a secure session key generation technique that prevents key compromise attacks.Moreover, with the secure session key generation technique the parties do not need to transmit a key over the network.In our paper, we use [29] in introducing our protocols.The methodology of [29] is demonstrated below.Let us assume that party A and party B share {  , DK, m}, where   stands for a long-term key, DK stands for a distributed key, and  is a random number.m is utilized to indicate the number of keys that will be produced.The conc(M1, M2, M3) shows the concatenation of each of the messages M1, M2, and M3, respectively.The secure session key generation technique process is shown in Figure 1.
After sharing {  , DK, m}, party A and party B create a set of preference keys   , where i = 1, . .., m, as follows:   = h( -1 , DK), where  0 =   .The set of   will be applied as an origin to invigorate session keys.K and DK can be removed from the system.
Next, party A and party B generate sets of intermediate keys to increase the difficulty for cryptanalysis.Moreover, this makes it more difficult to find the preference key if the session key is compromised.In each round, a new set of intermediate keys is produced.Note that the higher the number of rounds performed, the greater the security of the system.The intermediate key generation is performed as follows:    = ℎ(( -1  ),   -1 ), where  specifies the number of rounds and j specifies the number of intermediate keys that are generated, j = 1, . .., m.  -1  stands for the set of , and  1 1 =  3 .The generation of  1 ,  2 , and  3 is the same as that of   1 ,   2 , and   3 , respectively.  -1 = .The output of the last round of intermediate key generation is considered as session keys SK j , where j = 1, . .., m, which is shown below: . .,    =   .Party A and party B can then use SK j as a credential to secure transactions as, say, an encryption key or as an input to Message Authentication Codes.
It can be obviously seen that the session key is created purely offline.Each party can produce a set of session keys used to secure communication among themselves with no requirements to exchange credentials through the network, as a new session key is not transferred over the network.

Registration Phase.
It is assumed that mobile devices have the software based on installation of our protocols.Once the software is loaded, the client needs to log on to the payment system via a secure channel, e.g., TLS (Transport Layer Security).The protocol details are as follows: (1) The client establishes a TLS session and shares {  , DK CO ,   } with the mobile operator.The client and the mobile operator create a set of session keys SK COj by using the secure session key generation technique proposed in [29], where j = 1, . .., m.
(2) The client establishes a TLS session and shares {K CTTP , DK CTTP , m CTTP } with TTP.The client and TTP create a set of session keys SK CTTPj , using the secure session key generation technique proposed in [29], where j = 1, . .., m.

Purchase Credit Request Phase.
In this section, before the client pays for goods or services, the client purchases a topup cash card.The client runs the client software from his/her device.Next, he or she fills in the serial number of the top-up cash card and sends the following to the mobile operator: In message M1, the client sends message ID C , SN,  1 , h(SN, CL T ,  1 , SK COj ), {h(ID C , SN, CL T ,  1 )}  to the mobile operator.The message h(SN, CL T ,  1 , SK COj ) is considered as Message Authentication Code (MAC), which is an authentication token between the client and the mobile operator.Moreover, in order to guarantee information correctness and to defend against erroneous information alteration or destruction, the message {h(ID C , SN, CL T ,  1 )}  will be transmitted to TTP via the mobile operator.Note that  1 denotes the timestamp for the time when the purchase credit is requested and to prevent a replay attack.
In message M2, upon receiving this message from the client, the mobile operator sends the message {h(ID C , SN, CL T ,  1 )}  , {h(CL T ,  1 ,  2 )}  to TTP.
In message M3, TTP decrypts this message with SK CTTPj and SK OTTPj and keeps the hash value.TTP encrypts the hash value of {h(ID C , SN, CL T ,  1 ), h(CL T ,  1 ,  2 )} +1 with SK CTTPj+1 and encrypts the hash value of {h(ID C , SN, CL T ,  1 ), h(CL T ,  1 ,  2 )} +1 with SK OTTPj+1 .Then, TTP sends all the messages to the mobile operator.Note that  2 denotes the timestamp when the purchase credit is sent to a client and to prevent a replay attack.
In message M4, the mobile operator generates message h(CL T ,  1 ,  2 , SK COj+1 ), which is an authentication token between the client and the mobile operator.Moreover, this message is created in order to guarantee information correctness and to defend against erroneous information alteration or destruction.Then, the mobile operator sends message {h(ID C , SN, CL T ,  1 ), h(CL T ,  1 ,  2 )} +1 to the client.
In the above messages, the client supplies the serial number of the top-up cash card together with the requested credit limit to the mobile operator.Mobile operators can infer the credit limit from the serial number, given that the serial number is from a prepaid cash card.Note that serial numbers can also track the credit limit up to which the client is allowed to buy goods or services from the mobile operator.Note that an attacker cannot modify the serial number when the serial number is transmitted in clear text as it is key-hashed in h(SN, CL T ,  1 , SK COj ), which is a MAC with SK COj that is shared between the client and the mobile operator.After receiving the demand from the client, the mobile operator adds the credit limit value to the client's account and sends a message to the client.The mobile operator acknowledges the increment of the client's credit limit.During this phase, the client utilizes a top-up cash card in case they do not have enough credit to make the payment phase.

Making Payment Phase.
At the beginning of the protocol, the client and the merchant need to establish accounts with their mobile operator.The mobile operator will deduct a certain amount of value that is purchased by the client when he/she opens the account.There are two major functions on the client's side: application to operate searching and Making Payment for goods or services.The merchant is the seller of the goods or services on a mobile portal operated by the mobile operator.The protocol details are as follows: (1) The client establishes a TLS session and shares {  , DK CM ,   } with the merchant.The client and the merchant create a set of session keys SK CMj by using the secure session key generation technique proposed in [29], where j = 1, . .., m.
(2) The merchant establishes a TLS session and shares {  , DK MO ,   } with the mobile operator.The merchant and the mobile operator create a set of session keys SK MOj , using the secure session key generation technique proposed in [29], where j = 1, . .., m.
(3) The merchant establishes a TLS session and shares {K MTTP , DK MTTP , m MTTP } with TTP.They both establish a set of session keys SK MTTPj using the secure session key generation technique proposed in [29], where j = 1, . .., m.
(4) The client browses lists of goods or services via the application on his or her device.When the goods or services have been added to the cart, the client can make a payment by the protocol described below: In the case of message M1, the client sends message ID C , T, {ID M , OI, T, h(OI, SK CMj )}  , {h(ID C , ID M , OI, T)}  to the mobile operator.The message {ID M , OI, T, h(OI, SK CMj )}  is encrypted with SK COj , which is the session key shared between the client and the mobile operator for the mobile operation to verify authenticity of the client.It can be noted that the mobile operator does not know the session key SK CMj in order to construct the message h(OI, SK CMj ) since it cannot generate this message by itself.This message h(OI, SK CMj ) is considered as a Message Authentication Code (MAC), which is used to guarantee information correctness and to defend against erroneous information alteration or destruction.Moreover, it enables the merchant to verify authenticity of the client.The message {h(ID C , ID M , OI, T)}  will be transmitted to TTP via the mobile operator.It should be noted that  denotes the timestamp when the payment is requested and to prevent a replay attack.
In the case of message M2, upon receiving the message from the client, the mobile operator sends message {OI, h(OI, SK CMj ), h(OI, SK COj+1 ), T}  to the merchant to verify the authenticity of the mobile operator.The hash value of h(OI, SK CMj ) indicates that the mobile operator does not know the session key SK CMj that is used to construct the message h(OI, SK CMj ) since it cannot generate this message by itself.

Protocol
Communication cost (bits) [1] (1)+( 2)+(3)+( 4)+( 5)+( 6)+( 7)+( 8)+( 9  In the case of message M3, after receiving the message from the mobile operator, the merchant verifies the goods or services.If these are valid, a Yes message will be sent to the mobile operator, but if they are invalid a No message will be sent to the mobile operator and then the mobile operator will terminate the client's request.The merchant then sends the message {Yes/No, h(Yes, OI, SK CMj+1 )} +1 , {h(Yes, OI)}  to the mobile operator.The message that contains {Yes/No, h(Yes, OI, SK CMj+1 )} +1 is for the mobile operator to verify the authenticity of the merchant.It should be noted that the mobile operator does not know the session key SK CMj+1 that is used to construct the message h(Yes, OI, SK CMj+1 ) since it cannot generate this message by itself.This message contains h(Yes/No, OI, SK CMj+1 ) in order to guarantee information correctness and to defend against erroneous information alteration or destruction.The message {h(Yes, OI)}  will be transmitted to TTP via the mobile operator.
In the case of message M4, upon receiving this message from the merchant, the mobile operator checks the credit balance and compares it with the requested amount.If the client has enough credit, the mobile operator will reply with an Accept message to the client.If not, the mobile operator will reply with a Reject message, and then the client has to return to the Purchase Credit Request Phase.The mobile operator then sends message {h(ID C , ID M , OI, T)}  , {h(Accept/Reject, OI, CL RM )}  , {h(Yes, OI)}  to TTP.
In the case of message M5, after receiving the message from the mobile operator, TTP decrypts the message {h(ID C , ID M , OI, T)}  with SK CTTPj , {h(Accept/Reject, OI, CL RM )}  with SK OTTPj and {h(Yes, OI)}  with SK MTTPj , and it keeps the decrypted message to itself.Then TTP encrypts the message {h(ID C , ID M , OI, T), h(Accept/Reject, OI, CL RM ), h(Yes, OI)} +1 with SK CTTPj+1 , {h(ID C , ID M , OI, T), h(Accept/Reject, OI, CL RM ), h(Yes, OI)} +1 and encrypts the message with SK OTTPj+1 and {h(ID C , ID M , OI, T), h(Accept/Reject, OI, CL RM ), h(Yes, OI)} +1 .TTP also encrypts the message with SK MTTPj+1 and sends all the messages to the mobile operator.
In the case of message M6, the mobile operator forwards the message {h(ID C , ID M , OI, T), h(Accept/Reject, OI, CL RM ), h(Yes, OI)} +1 , which is encrypted by TTP with SK MTTPj+1 to the merchant.
In the case of message M7, the mobile operator encrypts message one {Accept/Reject, Yes, CL RM , h(Yes, OI, SK CMj+1 ), h(OI, SK MOj+1 )} +1 with SK +1 , while the message {h(ID C , ID M , OI, T), h(Accept/Reject, OI, CL RM ), h(Yes, OI)} +1 is encrypted by TTP with SK +1 to the client.The message that contains {Accept/Reject, Yes, CL RM , h(Yes/No, OI, SK CMj+1 ), h(OI, SK MOj+1 )} +1 is for the client to verify the authenticity of the mobile operator.It can be seen that the mobile operator cannot deny that the message has originated from him/her because only the mobile operator possesses both SK MOj +1 and SK COj+1 .This means that the mobile operator is the only one that can generate this message.The hash value of h(Yes/No, OI, SK CMj+1 ) notes that the mobile operator does not know the session key SK +1 that is used to construct the message h(Yes, OI, SK CMj+1 ) and the client to verify the authenticity of the merchant, since it cannot generate this message by itself.

Dispute Resolution Phase.
After the transaction is complete, if the client is not satisfied with the transaction, he/she can request a dispute resolution with the verifier.The dispute resolution protocols are composed of two subprotocols: Purchase Credit Request Phase and Making Payment Phase.Consider the protocols below.

Purchase Credit Request.
The client sends the hash value h(ID C , SN, CL T ,  1 ), h(CL T ,  1 ,  2 ) of the transaction to the verifier.Upon receiving the hash value from the client, the verifier sends the requested hash value of TTP.After receiving the hash value from TTP, the verifier compares the hash value from the client with a hash value from TTP.If the hash values do not match, the verifier rejects the client's request; if not, the verifier sends a notification of dispute resolution to the mobile operator to transfer the amount to the client's account.Note that the verifier stands for the external party and is a party that is not relevant to the particular transaction.

Making Payment. The client sends the hash value h(ID C , ID M , OI, T), h (OI, CL RM ), h(Yes/No, OI)
of the transaction to the verifier.Upon receiving the hash value from the client, the verifier sends the requested hash value of TTP.After receiving the hash value from TTP, the verifier compares the hash value from the client with a hash value from TTP.If the hash values do not match, the verifier rejects the client's request; if not, the verifier sends a notification of dispute resolution to the mobile operator to transfer the amount to the client's account and sends notification to the merchant.Note that the verifier stands for the external party and is a party that is not relevant to the particular transaction.
It is obvious that, in the Purchase Credit Request Phase (Section 3.5) and the Making Payment Phase (Section 3.6), all messages received by the TTP are only the hash values of the transactional data.Therefore, it is not possible for the TTP to

Security Analysis.
(1) Brute force attacks: for the completion of a transaction of our protocols, the session keys change every time and are not reused; therefore, it is difficult for the attacker to find the correct session key that is shared between parties.In addition, according to [29], a brute force attack is difficult to complete by applying an offline key generation technique.
(2) Replay attack prevention: the attacker intersects the message and resends an old message.Our protocols are used only once with a fresh timestamp, so a replay attack can be prevented and is difficult to accomplish.For further details about this technique, the reader is referred to [29].
(3) Message integrity: the integrity of the message is the most important security property that any party can ensure so that the message guarantees information correctness and is defended against erroneous information alteration or destruction during the transmission.With our protocols, each message comprises a Message Authentication Code (MAC) value that ensures the recipient of the message, and the same recent key can be used to generate a new MAC.The received MAC is compared with the calculated MAC.
(4) Mutual authentication: this is used to check who the originator and the receiver of a message are.Our protocols deploy MACs and symmetric cryptographic operations.Only the originator and the receiver who share the same key will be able to encrypt and decrypt their messages.As a result of our protocols, each message can be used to identify the originator and the receiver so that the client, the merchant, and the mobile operator ensure mutual authentication.Consider the message below:

M : C 󳨀→ O: ID C , T, {ID M , OI, T, h(OI, SK CMj )} 𝑆𝐾𝐶𝑂𝑗 , {h(ID C , ID M , OI, T)} 𝑆𝐾𝐶𝑇𝑇𝑃𝑗
It can be seen that the client and the mobile operator share the session key SK COj , but the mobile operator cannot generate this message by himself or herself because the mobile operator cannot generate h(OI, SK CMj ), as the session key SK CMj is shared only between the merchant and the client.Only the session keys SK CMj and SK COj are known by the client, therefore guaranteeing that the client generated this message.
(5) Man-in-the-middle attacks: an attacker cannot impersonate a party by intercepting message passes in these protocols.With the use of limited-use session keys and proper cryptographic operations, no confidential information is revealed and the reuse of authentication information is limited.In addition, the session keys used in our protocols are changed constantly using strong encryption techniques  The formula X is fresh The formula X is encrypted under the key K (X) K The hash value of X using K as key and therefore it is not possible for the transmitted message to be analyzed by an attacker who fraudulently feigns a party.(6) Nonrepudiation of transactions: ordinarily, an encrypted message with the private key of a public key encryption operation provides a nonrepudiation property: a party cannot decline the transactions he or she has performed.However, an encrypted message with a symmetric key of symmetric key encryption operations cannot provide a nonrepudiation property.Nevertheless, nonrepudiation properties can be satisfied by encrypting messages with a symmetric key encryption.Being able to collect evidence from each message, our protocols demonstrate the actions that all parties have performed in each transaction.To see the nonrepudiation properties of our proposed protocols, see the message below:

M : C 󳨀→ O: ID C , T, {ID M , OI, T, h(OI, SK CMj )} 𝑆𝐾𝐶𝑂𝑗 , {h(ID C , ID M , OI, T)} 𝑆𝐾𝐶𝑇𝑇𝑃𝑗
It can be seen that the client cannot decline that the message he/she generated originated from him/her.This is because only the client possesses both SK CMj and SK COj .This indicates that only the client can generate this message.
(7) Confidentiality: generally, symmetric key encryption operations provide confidentiality of the security properties of the messages.Every message of our protocols applies symmetric key encryption operations to lead the confidentiality of the messages.The same session keys shared between the sender and receiver will be able to encrypt and decrypt their messages.
(8) SMS disclosure: at present, the confidentiality and integrity of the message do not provide the transmission of the SMS message.Our protocols use symmetric key encryption and hash functions to satisfy confidentiality and integrity from SMS disclosure of all the messages.( 9) Over-the-air modification: although the global system for a mobile communication network uses cryptographic techniques of A5/1 and A5/2 between the mobile device and the base station subsystem, they are still vulnerable [1][2][3][4].Our protocols provide end-to-end security from the sender to the receiver by a strong encryption algorithm (such as AES).
(10) Impersonation attack: an attacker who impersonates a party cannot complete the attack because each message in our protocols provides mutual authentication of all parties of the transactions.Moreover, each message can be used to identify the sender and the receiver who share the same session keys.Our protocols can prevent impersonation attacks.
(11) SMS spoofing: an attacker can spoof the client by sending an SMS message with the correct headers via the Internet.Our protocols utilize a secure session key generation technique, in that only the sender and the receiver who share the same key will be able to encrypt and decrypt their messages.Moreover, our protocols on all parties provide mutual authentication.It can be seen that our protocols prevent SMS spoofing attacks.

Formal Security Verification of Our Protocols.
The Scyther tool is used to verify the robustness and soundness of our protocols.The Scyther tool is a formal proofreader for security protocols.It is an automated security protocol analysis tool based on Security Protocol Description Language (SPDL), Scyther [36,37].SPDL provides three main protocol modelling features: roles, events, and claims.A lot of researchers have now utilized the Scyther tool to validate security protocols; see [25,[38][39][40][41].The following security claims are verified in the analysis: secrecy of data (Secret), aliveness (Alive), weak agreement (Weakagree), noninjective agreement (Niagree), and noninjective synchronization (Nisynch) [37].Our protocols are verified using the "Verification Claim" scheme in the Scyther tool.
Figures 2 and 3 display the SPDL script for verifying our protocol.Figures 4 and 5 show the output of the tests of our proposed protocols.Most of the claims are utilized to verify  the security properties with a status (OK) for all the claims, and no attacks are discovered within bounds.

Performance Analysis of the Proposed Protocols.
Our performance analysis follows the analysis of the mobile payment protocols [1,3,[5][6][7][8][9]25] and the fair exchange protocols [11,13,15,17,21,24,26] by focusing on several aspects related to the transaction performance, e.g., the number of cryptographic operations applied to each protocol and the number of messages passed in each protocol.We then show that our protocols have a greater performance than other existing SMS payment and fair exchange protocols.Our protocols utilize the symmetric encryption Advanced Encryption Standard (AES) 128 bits.
Tables 2 and 3 show symbols and abbreviations and cryptographic operation functions for use in this part of the paper in order to complete performance analysis.Table 4 illustrates the message length of our protocols, which are considered as a lightweight cryptographic operation.Moreover, the message length of our protocols is less than the maximum message length of an SMS (160 bytes) in messages M1 and M4 (Purchase Credit Request Phase) and in messages M1 and M7 (Making Payment).Our protocols can be implemented in the current SMS infrastructure and therefore maintain ease of use.
Table 5 shows the SMS overhead of our protocols.The SMS overhead is calculated only with transactions between the client and the mobile operator.The client sends M1 (Purchase Credit Request Phase) to the mobile operator.The mobile operator sends M4 (Purchase Credit Request Phase) to the client.The client sends M1 (Making Payment) to the mobile operator.The mobile operator sends M7 (Making Payment) to the client.It can be seen that our protocols generate a minimum SMS overhead.Besides, the SMS overhead of our protocols is less than the maximum SMS overhead of an SMS (160 bytes).
Table 6 demonstrates the comparison of the cryptographic operations of our protocols with the proposed protocols in [1,3,[5][6][7][8][9]25].Our protocols utilize different cryptography techniques such as a hash function and symmetric encryption.It can be inferred that our protocols use the minimum cryptographic operation.
The energy consumption of our protocols, according to [42], presents a framework for the energy consumption analysis of security protocols and cryptographic algorithms such as asymmetric, symmetric, hash function, and Message Authentication Code (MAC) algorithms.A number of frameworks have been proposed [43][44][45].
Table 11 illustrates a fairness comparison between our proposed protocols and existing mobile payment protocols [1,3,[5][6][7][8]25].As can be seen in Table 11, protocols proposed in [1,3,[5][6][7][8]25] have no trusted third party involved.Hence, those protocols do not have fairness according to the model presented in Section 3.2.Minta and Panchami [9] proposed an efficient encryption protocol for secure transmission of a confidential SMS.The Certification Authority and Registration Authority (CA/RA) are a trusted third party.It can read important information because CA/RA maintains a database containing the certificates of PK-SIM cards and Secure Access Gateway (SAGs) and Certificate Revocation Lists (CRLs).Thus, this protocol is weak in terms of fairness.In contrast, our proposed protocols satisfy the strong fairness as described Section 3.2.
Table 12 illustrates the comparison of the fairness aspect of different protocols.Mohammed [13] presented a transfer protocol ownership.The transaction server can read important information: a contract to be signed by both the buyer and the seller by the private key of the transaction server, the results of verification, buyer's account number, seller's account number, and amount.Hence, Mohammed's protocol is weak in terms of fairness according to the model described in Section 3.2.Chen [26] proposed a fair transaction model in mobile commerce, which is based on a personal trusted device.The customer of the business can read a considerable amount of information: the details of their purchases, the delivery address (which may be an email address or a physical address), dates, billing addresses, shipping addresses, the customer's own account, and the total price.Thus, Chen's protocol is also weak in terms of fairness.Alotaibi [15] proposed a new fair exchange protocol for trading goods online.The financial service provider can read all significant information: digital goods and invoices that are encrypted with temporary session keys of the financial service provider in the pre-exchange phase, the name of the financial institution of the customer, personal information about the customer, account details of the customer, and the total amount of money that the customer will pay for the digital goods.These are encrypted with the private key of the customer in the exchange phase.Therefore, Alotaibi's protocol is weak in terms of fairness.Mohammed [21] proposed fair exchange protocols between a customer and a merchant.The trusted third party can read important information: payments that are encrypted with the private key of the customer and digital goods that are encrypted with the session key of the merchant that is encrypted with the public key of the trusted third party.Therefore, Mohammed's protocol is also weak in terms of fairness.Alaraj [23] proposed a fair certified email protocol.The trusted third party can read a considerable amount of information: the mail that is encrypted with its sender's session key that is encrypted with the public key shared between the sender and the trusted third party.The trusted third party can decrypt messages with the private key shared between the trusted third party and the sender in the recovery subprotocol.Hence, Alaraj's protocol is weak in terms of fairness.Hinarejos [24] proposed an efficient and provable fair document exchange protocol.The trusted third party can read a considerable amount of information, such as parameters, which generate a session key to encrypt the document of party A and party B. Thus, Hinarejos's protocol is weak in terms of fairness.Liu [17] proposed a nonrepudiation protocol, which is based on a receiver-side smart card.The trusted third party can read significant information: a message to be exchanged between the customer and the vender.This message is encrypted with a session key generated by the trusted third party.Therefore, Liu's protocol is weak in terms of fairness.Paulin [11] proposed a fair nonrepudiation certified email protocol.This protocol either does or does not involve the trusted third party as the mediator between the senders and the receivers.In this way, Paulin's protocol has no fairness.Our protocols satisfy strong fairness according to the model presented in Section 3.2.
Table 13 shows a comparison of the security properties of the protocols found in the literature [1, 3, 5-7, 9, 25] and our protocols.It is clear that our protocols and [8] satisfy the necessary security properties, which are confidentiality, integrity, mutual authentication, nonrepudiation, brute force attack, replay attack prevention, man-in-the-middle attack and SMS disclosure, over-the-air modification, impersonation attack, and SMS spoofing.Note that Y and N mean "satisfying" and "unsatisfying".

Analysis of Fairness
In this section, we analyze our proposed protocols in terms of the fairness properties of the Purchase Credit Request Phase and the Making Payment Phase.We also provide some guidelines to prove the fairness of our proposed protocols.It can be seen that, to complete a transaction in the client's opinion, the payment-order response from the mobile operator must contain the amount requested by the client, and the debit response from the mobile operator must contain the amount where the client has requested the mobile operator to deduct from his/her account.In other words, the client not only has to receive payment responses, but also has to receive payment-order and debit from the mobile operator (on behalf of the mobile operator), respectively.All requests are sent to the trusted third party.According to the model stated in Section 3.2, our protocols then satisfy the fairness properties for all parties: the clients, the mobile operator, and the merchant.
Our analysis of fairness is derived from [46].The reader may find more details about Kungpisdan's logic from [46].

Terms
(i) {P, Q, R, V}: a set of engaging parties (ii) {X, Y}: a set of messages or message components in a protocol (iii) {}: a set of statements derived from messages (iv) X applied with a single-key operation with key K. ⟨X⟩ K can be any kind of message that is relevant to a single key, MAC (Message Authentication Code), or (viii) even h(K) (ix) K-is-deriving-key-for-⟨X⟩ K : K can be used as a key to derive message  from a single-key cryptographic message

Formulae
(i) P believes : P believes that the statement  is true.
(ii) P sees X: Some party has sent a message  to  and  is able to read X.
(iii) P has X: P possesses a message X. P can send  to other parties or use it for further computations.
(iv) P says X: P has sent message X.
(v) P CanProve  to Q: P can prove to  that statement  is true.
(vi) P authorized payment (P, Q, OI, datetime): P has authorization to make the payment amount Price to  on datetime, the datetime of transaction.
(vii) P authorized debit (P, Q, OI, datetime): P has authorization to request  to deduct the amount Price from P's account on datetime, the datetime of transaction.
(viii) P authorized credit (P, Q, OI, datetime): P has authorization to request  to transfer the amount Price to P's account on datetime, the datetime of transaction.
5.4.Initial Assumptions.The following assumptions are specific to our fairness protocols.

General Assumptions.
A : Every party believes that if  believes that K' is shared between parties  and R, V has both ⟨X⟩ K and K', and K' can be used to extract  from ⟨X⟩ K' , then  believes that ⟨X⟩ K is shared between  and R.

P believes [(V believes Q
Here  and  stand for any two participants; assumption A1 together with axiom P2 is used for reason that if  believes that  is a secret shared between two parties, then any message that is applied with the single-key operation relevant to  must be considered a shared secret as well.
A : Every party believes that if  believes that he/she does not generate ⟨X⟩ K by himself/herself, K' is shared between P' and Q, V has both ⟨X⟩ K and K', and K' can be used to extract  from ⟨X⟩ K' , then  believes that  has sent  to party P'.P believes (V believes P' sees ⟨X⟩ K ⋀ V believes P' A : Every party believes that if  has messages  and  and message  is h(Y), then  believes that  is the fingerprint of Y.

P believes [(V has (X, Y) ⋀ X = h(Y) ) 󳨀→ V believes X-isfingerprint-of-Y]
A : Every party believes that if  has key K' and the single-key cryptographic message ⟨X⟩ K and K' can be used to derive ⟨X⟩ K , then V believes that K' is the deriving key for ⟨X⟩ K .
P believes (V has ⟨X⟩ K , K') ⋀ X = ⟨⟨X⟩ K ⟩ K' → V believes K'-is-deriving-key-for-⟨X⟩ K ) 5. 4 ←  →O Here  denotes any participant, N denotes a message or a message component,  1 denotes the message that is different from SK CM and {}  ,  2 denotes the message that is different from SK CO and {}  , and  3 denotes the message that is different from SK MO and {}  .

Payment Information. A :
The client and the merchant believe that they possess the price and statement.
Q believes Q has (OI) where  denotes  and .Note that the merchant has OI because he/she has the information about goods or services such as the description and price.

Payment Authorizations.
A : Each player believes that he/she can prove to the verifier that if the client has sent the message containing ID M identity, price, and the datetime of transaction, the client has authorization to order goods or services from the merchant.
P believes P CanProve (C says (ID M , OI, datetime) → C authorized payment-order(C, M, OI, datetime)) to V Each player believes that he/she can prove to the verifier that if the merchant has sent the message containing ID C , price, and the datetime of the transaction, the merchant has authorization to issue the payment receipt to the client.
P believes P CanProve (M says (ID C , OI, datetime) → M authorized payment-order(C, M, OI, datetime)) to V Each player believes that he/she can prove to the verifier that if the mobile operator has sent the message containing ID C , OI, and the datetime of transaction, the mobile operator has authorization to debit from the client's account.
P believes P CanProve (O says (ID C , OI, datetime) → O authorized debit(C, O, OI, datetime)) to V Each player believes that he/she can prove to the verifier that if the client has sent the message containing OI and the datetime of the transaction, then the client has authorization to request the mobile operator to deduct the requested amount from his/her account.
P believes P CanProve (C says (OI, datetime) → C authorized debit(C, O, OI, datetime)) to V Each player believes that he/she can prove to the verifier that if the mobile operator has sent the message containing ID M , OI, and the datetime of the transaction, then the mobile operator has authorization to transfer the requested amount to the account of the merchant.

P believes P CanProve (O says (ID M , OI, date)
→ O authorized credit(M, O, OI, datetime)) to V Each player believes that he/she can prove to the verifier that if the merchant has sent the message containing OI and the datetime of the transaction, then the merchant has authorization to request the mobile operator to transfer the requested amount to the merchant account.
P believes P CanProve (M says (OI, datetime) → M authorized credit(M, O, OI, datetime)) to V 5.5.The Goals of Analysis.To evaluate the fairness, we specify the goals regarding the fundamental interactions between pairs of engaging parties: the payment-order between the client and the merchant, the debiting between the client and the mobile operator, and the crediting between the merchant and the mobile operator.We state the goals G1-G6 by associating them with the abilities to prove the primitive interactions stated in Section 3. Detail of the proof can be shown as follows: The goal G4 is successfully proved.Thus, it can be concluded that the merchant is satisfied with the fairness.Note that the details of the analysis of goals G1-G3 and G5-G6 were successfully analyzed.
Consider message 2 of Making Payment Phase.

G : M believes M CanProve (C authorized paymentorder(C, M, OI, datetime)) to V
Consider  The goal G1 is successfully proved.Thus, it can be concluded that the merchant is satisfied with the fairness.Note that the details of the analysis of goals G2-G6 were successfully analyzed.

Security Proof Based on BAN Logic
We use BAN logic model to prove the mutual authentication of our protocols.The BAN logic [27] is a well-known formal model, which is used to examine the security of mutual authentication.The literature in [47] The goals are successfully proved in Purchase Credit Request Phase.Thus, it can be concluded that all parties have satisfied a secure mutual authentication.←  →  5

Making Payment
The goals are successfully proved in the Making Payment Phase.Thus, it can be concluded that all parties have satisfied a secure mutual authentication.

Conclusion
In this paper, we have introduced protocols for mobile payments that satisfy the important attributes of both strong fairness and security of sale transactions.Those security properties include confidentiality, integrity, mutual authentication, and nonrepudiation.The notion of our approach is suitable for the existing SMS infrastructure.This is because hash functions have been employed, which keep the sizes of all messages small enough to fit the limitation of the SMS system.Moreover, our protocols have deployed the techniques of offline session key generation and distribution to create the transaction security while being able to retain the lightweight property.Based on our analysis, it has been proven that our protocols are more effective than others in terms of information security and strong fairness of the exchange.All of our protocols have been successfully analyzed using the Scyther and BAN logic tools to verify their completeness and soundness.

3. 1 .
Notations and Assumptions.The protocols comprise four parties: a client or C, a merchant or M, a mobile operator or O (payment gateway), and a trusted third party or TTP.Clients need to install the proposed software on their mobile devices.The client who establishes an account with a mobile operator pays monthly fees.(i) ID A is the identity of A.

Figure 2 :
Figure 2: SPDL script of Purchase Credit Request Phase.

Figure 4 :
Figure 4: Output of Purchase Credit Request Phase.

Figure 5 :
Figure 5: Output of Making Payment Phase.

Table 1 :
Advantages and disadvantages of the types of fairness.

Table 4 :
Message length of our protocols.

Table 5 :
SMS overhead of our protocols.

Table 6 :
Comparison of cryptographic operations.

Table 7 :
Comparison of energy consumption.

Table 11 :
Comparison of mobile payment protocols.

Table 12 :
Comparison of fair exchange protocols.
If  is a theorem, then  believes  is a theorem, where theorem is a formula, which can be derived from axioms alone.5.3.3.Possessions.H : P sees X → P has X.H : (P has  1 ⋀ . ..⋀P has   ) ←→ P has ( 1 , ...,   ), where ( 1 , ...,   ) stands for a list of messages  1 ,  2 , ...,   , respectively.If  has {M, X}  and a key K', P believes that K' is shared between  and a party P', P can prove to  that K' can be used to decrypt {M, X}  , and  can also prove to  that  is shared between  and R, and then  can prove to  that  has sent  to P'.[P has ({M, X}  , K') ⋀ P believes P' 5.3.Axioms 5.3.1.Comprehensions.C : P sees X → P believes P sees X 5.3.2.Inference Rules.M: H : P has X → P has h(X).
.2. Possessions.A : Each player has their own identities. believes  has   , C believes C has   , M believes M has   , O believes O has   , O believes O has ID C .The client and the merchant believe that SK CM and {}  are shared between them, and they also have SK CM .The client and the mobile operator believe that SK CO and {}  are shared between them, and they also have SK CO .The merchant and the mobile operator believe that SK MO and {}  are shared between them, and they also have SK MO .P believes P has SK CM where  denotes  and M, and  is a message.  ←  →O, R believes R has SK MO where  denotes  and O.A : Each player believes that the merchant does not receive SK CO , the mobile operator does not receive SK CM , and the client does not receive SK MO . believes ¬ M sees   ,  believes ¬ O sees   , Details of the Proof.Due to the limited space, we are not able to describe all details of our fairness analysis.However, we can provide some guidelines to prove G4 of the Purchase Credit Request Phase and G1 of the Making Payment Phase as follows.Consider message 4 of Purchase Credit Request Phase, M : O → C:  2 , h(CL T ,  1 ,  2 , SK COj+1 ), {h(ID C , SN, CL T ,  1 ), h(CL T ,  1 ,  2 )} +1 It can be transformed into: C sees  2 , h(CL T ,  1 ,  2 , SK COj+1 ), {h(ID C , SN, CL T ,  1 ), h(CL T ,  1 ,  2 )} +1