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

Thammarat, Chalee; Kurutach, Werasak

doi:https://doi.org/10.1155/2018/6953160

Wireless Communications and Mobile Computing

On this page

Abstract Introduction Related Works Discussion Conclusion Conflicts of Interest Acknowledgments References Copyright Related Articles

Research Article | Open Access

Volume 2018 | Article ID 6953160 | https://doi.org/10.1155/2018/6953160

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

Chalee Thammarat¹and Werasak Kurutach¹

Academic Editor: Javier Aguiar

Received30 Aug 2017

Revised18 Jan 2018

Accepted17 Apr 2018

Published05 Jul 2018

Abstract

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.

1. 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–4]. During the past few years, many researchers have investigated protocols for mobile payments with fair exchange [1, 3, 5–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. 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.

Generally, there are two types of fairness protocols. One requires the involvement of a trusted third party (TTP), but the other does not [10–12]. The former can be further divided into three categories: inline [10, 13, 14], online [7, 10, 12, 15–17], and offline [10, 11, 18–24]. In our work, we will emphasize the fairness protocols that involve the online TTP. In this section, we will briefly describe previous works related to this topic.

A number of mobile payment protocols have been proposed [1, 3, 5–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-the-middle attack, replay attack, SMS disclosure, and over-the-air 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.

3. 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.

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.(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.

3.2. 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:

M CanProve (C authorized payment-order(C, M)) to V ⋀

PG CanProve (C authorized debit(C, PG)) to V ⋀

C CanProve (PG authorized debit(PG, C)) to V ⋀

C CanProve (M authorized payment-order(M, C)) to V ⋀

TTP CanProve (C authorized Log(C, TTP)) to V ⋀

C CanProve (TTP authorized Log(TTP, C)) to V

C satisfies payment-order(C, M, TTP)

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:

M CanProve (C authorized payment-order(C, M)) to V

PG CanProve (M authorized credit(M, PG)) to V ⋀

M CanProve (PG authorized credit(PG, M)) to V ⋀

C CanProve (M authorized payment-order(M, C)) to V ⋀

TTP CanProve (M authorized Log(M, TTP)) to V ⋀

M CanProve (TTP authorized Log(TTP, M)) to V

M satisfies credit (M, PG, TTP)

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 CanProve (C authorized debit (C, PG)) to V ⋀

PG CanProve (M authorized credit (M, PG)) to V ⋀

R CanProve (PG authorized payment-clearing (PG, C, M)) to V ⋀

TTP CanProve (PG authorized Log(PG, TTP)) to V ⋀

PG CanProve (TTP authorized Log(TTP, PG)) to V

PG satisfies payment-clearing (PG, C, M, TTP)

It can be seen that the payment gateway will satisfy a transaction if the payment gateway has performed payment-clearing 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.

3.3. 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 papers [29, 31–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(, DK), where = . 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: , where specifies the number of rounds and j specifies the number of intermediate keys that are generated, j = 1, …, m. stands for the set of . and is the remaining number of intermediate keys in the set of . . . , , and . The generation of , , and is the same as that of , , and , respectively. . 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.

3.4. 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.

3.5. Purchase Credit Request Phase

In this section, before the client pays for goods or services, the client purchases a top-up 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:

M1: C O: , SN, , h(SN, CL_T, , SK_COj), h(, SN, CL_T, )

M2: O TTP: h(ID_C, SN, CL_T, ), h(CL_T, , )

M3: TTP O: h(ID_C, SN, CL_T, ), h(CL_T, , ), h(ID_C, SN, CL_T, ), h(CL_T, , )

M4: O C: , h(CL_T, , , SK_COj+1), h(ID_C, SN, CL_T, ), h(CL_T, , )

In message M1, the client sends message ID_C, SN, , h(SN, CL_T, , SK_COj), h(ID_C, SN, CL_T, to the mobile operator. The message h(SN, CL_T, , 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, will be transmitted to TTP via the mobile operator. Note that 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, , h(CL_T, , 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, ), h(CL_T, , with SK_CTTPj+1and encrypts the hash value of h(ID_C, SN, CL_T, ), h(CL_T, , with SK_OTTPj+1. Then, TTP sends all the messages to the mobile operator. Note that 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, , , 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, ), h(CL_T, , 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, , 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.

3.6. 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:

M1: C O: ID_C, T, ID_M, OI, T, h(OI, SK_CMj), h(ID_C, ID_M, OI, T)

M2: O M: OI, h(OI, SK_CMj), h(OI, SK_COj+1), T

M3: M O: Yes/No, h(Yes, OI, SK_CMj+1), h(Yes, OI)

M4: O TTP: h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI)

Otherwise, the mobile operator terminates the client’s request.

M5: TTP O: h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI), h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI), h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI)

M6: O M: h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI)

M7: O C: Accept/Reject, Yes, CL_RM, h(Yes, OI, SK_CMj+1), h(OI, SK_MOj+1), h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, IO)

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.

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), h(Yes, OI) to the mobile operator. The message that contains Yes/No, h(Yes, OI, SK_CMj+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) with SK_CTTPj+1, h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI) 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). 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), 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) with SK_COj+1, while the message h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI) is encrypted by TTP with SK_CTTPj+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) 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_CMj+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.

3.7. 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.

3.7.1. Purchase Credit Request

The client sends the hash value h(ID_C, SN, CL_T, ), h(CL_T, , ) 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.

3.7.2. 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 access meaningful information of the transaction. This makes our protocols have strong fairness.

4. Discussion

4.1. 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:

M1: 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 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:

M1: 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–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.

4.2. 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–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.

4.3. Performance Analysis of the Proposed Protocols

Our performance analysis follows the analysis of the mobile payment protocols [1, 3, 5–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–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–45].

Table 7 shows the energy cost comparison of our protocols with other protocols [1, 3, 5–9, 25]. It can be seen that our protocols use a lower energy cost than the protocols proposed in [5–9, 25]. The protocols in [1, 3, 9] use less energy than our protocols. However, our protocols have a smaller number of messages than the protocols proposed in [1, 3, 9], so they take less time to accomplish every correlated transaction [1, 3, 9].

Table 8 and Figure 6 demonstrate comparisons of communication cost between the proposed protocols and existing protocols in [1, 3, 5–9, 25]. It can be seen that the proposed protocols has a higher communication cost than the protocols proposed in [1, 3, 5–9, 25]. Nevertheless, the SMS mobile payment protocols in [1, 3, 5–9, 25] are weak in terms of fairness according to the model described in Section 3.2. Moreover, in the case that one party misbehaves, the protocols proposed in [1, 3, 5–9, 25] cannot resolve any dispute because they do not provide the dispute resolution phase. Note that n is number of transactions.

From Table 9 and Figure 7, the protocols proposed in [1, 3, 5–9, 25] have lower computational cost than our protocols.

Table 10 and Figure 8 compare the storage costs of the protocols found in [1, 3, 5–9, 25] with the one of our protocols. It is clear that our protocols have a higher storage cost than the protocols proposed in [1, 3, 5, 6, 8, 9] but lower than the ones in [7, 25].

Table 11 illustrates a fairness comparison between our proposed protocols and existing mobile payment protocols [1, 3, 5–8, 25]. As can be seen in Table 11, protocols proposed in [1, 3, 5–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”.

5. 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].

5.1. 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) Q: key K can be used to refer to Q(v)P Q: key is the shared key between and Q(vi)X-is-fingerprint-of-Y: X is a fingerprint of Y(vii)〈X〉_K: 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

5.2. 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.3. Axioms

5.3.1. Comprehensions

C1: P sees X P believes P sees X

5.3.2. Inference Rules

M: 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

H1: P sees X P has X.

H2: (P has ⋀ …⋀ P has ) P has (, …, ), where (, …, ) stands for a list of messages , , …, , respectively.

H3: P has X P has h(X).

H4: (P has (, K) ⋀ P believes P Q) P has X.

5.3.4. Provability

P2: [V-is-external-party ⋀ P has X ⋀ (V sees X V believes φ)] P CanProve φ to V.

P3’: 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’ Q ⋀ P CanProve () to V

⋀ P CanProve (Q R) to V]

P CanProve (Q says (M, X, ID_P’)) to V

P6: P CanProve (Q says (, …, )) to V

[P CanProve (Q says ) to V ⋀…⋀ P CanProve (Q says ) to V]

5.4. Initial Assumptions

The following assumptions are specific to our fairness protocols.

5.4.1. General Assumptions

A1: 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 R ⋀ V has (〈X〉_K, K’) ⋀ X = 〈〈X〉_K〉_K’) V believes Q R]

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.

A2: 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’ Q ⋀ V has (〈X〉_K’, K’) ⋀ X = 〈〈X〉_K〉_K’ V believes Q says (X, ID_P’))

A3: 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-is-fingerprint-of-Y]

A4: 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.2. Possessions

A5: Each player has their own identities.

, ,

O believes O has ID_C.

5.4.3. Shared Secrets

A6: 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 CM, P believes CM, P believes P has SK_CM where denotes and M, and is a message.

Q believes CO, P believes CO, Q believes Q has SK_CO where Q denotes C and O.

R believes MO, R believes MO, R believes R has SK_MO where denotes and O.

A7: 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.

, ,

P believes C sees SK_MO

5.4.4. Verifier’s Beliefs

A8: Each player believes that the verifier is an external party to whom every participant is able to reveal its secrets.

P believes V-is-external-party

Q believes V believes CM, Q believes V believes CM, Q believes V believes CO

Q believes V believes CO, Q believes V believes MO, Q believes V believes MO

Q believes V believes CO, Q believes ¬V believes CO, Q believes V believes MO

Here denotes any participant, N denotes a message or a message component, denotes the message that is different from SK_CM and , denotes the message that is different from SK_CO and , and denotes the message that is different from SK_MO and .

5.4.5. Payment Information

A9: 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.

5.4.6. Payment Authorizations

A10: 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.2 as follows:

G1: M believes M CanProve (C authorized payment-order(C, M, OI, datetime)) to V

G2: C believes C CanProve (M authorized payment-order(M, C, OI, datetime)) to V

G3: O believes O CanProve (C authorized debit(C, O, OI, datetime)) to V

G4: C believes C CanProve (O authorized debit(O, C, OI, datetime)) to V

G5: O believes O CanProve (M authorized credit(M, O, OI, datetime)) to V

G6: M believes M CanProve (O authorized credit(O, M, OI, datetime)) to V

5.6. 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.

G4: C believes C CanProve (O authorized debit(O, C, OI, datetime)) to V

Consider message 4 of Purchase Credit Request Phase,

M4: O C: , h(CL_T, , , SK_COj+1), h(ID_C, SN, CL_T, ), h(CL_T, ,

It can be transformed into:

C sees , h(CL_T, , , SK_COj+1), h(ID_C, SN, CL_T, ), h(CL_T, ,

Detail of the proof can be shown as follows:

C sees T₂, h(CL_T, T₁, T₂, SK_COj+1), h(ID_C, SN, CL_T, T₁), h(CL_T, T₁, T₂)
1, C1, M: C believes C sees T₂, h(CL_T, T₁, T₂, SK_COj+1), h(ID_C, SN, CL_T, T₁), h(CL_T, T₁, T₂).
2, H1, H2, M: C believes C has T₂, h(CL_T, T₁, T₂, SK_COj+1), h(ID_C, SN, CL_T, T₁), h(CL_T, T₁, T₂)
3, A6, H2, M: C believes C has T₂, h(CL_T, T₁, T₂, SK_COj+1), CL_T, T₁, SK_COj+1
A7, 4, A2, P2, M: C believes V-is-external-party ⋀
C believes C has T₂, h(CL_T, T₁, T₂, SK_COj+1), CL_T, T₁, SK_COj+1 ⋀
C believes (V believes (CO) ⋀
V believes C sees h(CL_T, T₁, T₂, SK_COj+1) ⋀
V has T₂, h(CL_T, T₁, T₂, SK_COj+1), CL_T, T₁, SK_COj+1 ⋀
h(CL_T, T₁, T₂, SK_COj+1) = h(CL_T, T₁, T₂, SK_COj+1)
V believes O says (CL_T, T₁, T₂)
C believes C CanProve (O says CL_T, T₁, T₂) to V
5, P6, M: C believes C CanProve (O says CL_T, T₁, T₂) to V

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.

G1: M believes M CanProve (C authorized payment-order(C, M, OI, datetime)) to V

Consider message 2 of Making Payment Phase,

M2: O M: OI, h(OI, SK_CMj), h(OI, SK_COj+1), T

It can be transformed into:

M sees OI, h(OI, SK_CMj), h(OI, SK_COj+1), T

Detail of the proof can be shown as follows:

M sees OI, h(OI, SK_CMj), h(OI, SK_COj+1), T
1, C1, H1, H2, M: M believes M has OI, h(OI, SK_CMj), h(OI, SK_COj+1), T
2, A6, H2, M: M believes M has (OI, h(OI, SK_CMj), h(OI, SK_COj+1), T)
A7, 3, A5, P2, M: M believes M CanProve (SK_MOj-is-decrypting-key-for-OI, h(OI, SK_CMj), h(OI, SK_COj+1), T) to V
3, A6, H4, M: M believes M has (OI, h(OI, SK_CMj), h(OI, SK_COj+1), T)
5, H2, M: M believes M has h(OI, SK_CMj)
4, H3, M: M believes M has (h(OI))
7, A5, H2, M: M believes M has (h(OI), SK_CMj)
A7, 6, 8, H2, A1, P2, M: M believes M CanProve (CM) to V
3, A6, 4, 9, P3', M: M believes M CanProve (C says (OI, h(OI, SK_CMj), T)) to V
10, P6, M: M believes M CanProve (C says (OI, T)) to V
11, A9, M: M believes M CanProve (C authorized payment-order(C, M, OI)) to V

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.

6. 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] has now utilized the BAN logic to verify the security of mutual authentication. The notations used in BAN logic are defined in Table 14.

Moreover, the proposed protocols use six rules of BAN logic to prove a secure mutual authentication between parties:

R1. Message-meaning rule: , .

R2. Nonce-verification rule: .

R3. Jurisdiction rule: .

R4. Freshness rule: .

R5. Belief rule: .

R6. Decryption rules: .

We analyze both Purchase Credit Request and Making Payment Phases in order to complete a secure mutual authentication of all parties. Our protocols are listed as follows.

6.1. Purchase Credit Request Phase

6.1.1. Idealized Form

M1: C O: (SN, CL_T, , C ) M4: O C: (CL_T, , , C )

6.1.2. Initial Assumptions

A1. O|≡ O, A2. C|≡ CO, A3. O|≡ #(), A4. C|≡ #()

6.1.3. The Goals of Analysis

G1. O|≡(SN, CL_T, , C ), G2. C|≡(CL_T, , , C )

6.1.4. Details of the Proof

G1. O|≡(SN, CL_T, , C )

O(SN, CL_T, , C ) from message M1	1
1, R1: O\|≡O⊲(SN, CL_T, , C )	2
2, R2, R4, A1, A3: O\|≡O has (, C )	3
3, R5: O\|≡O has (SN, CL_T)	4
4: O\|≡(SN, CL_T, , C )	5
G2. C\|≡(CL_T, , , C )
C⊲(CL_T, , , C ) from message M4	1
1, R1: C\|≡C⊲(CL_T, , , C )	2
2, R2, A2: C\|≡C has (CL_T, , C )	3
3, R4, R5, A4: C\|≡C has ()	4
4: O\|(CL_T, , , C )	5

The goals are successfully proved in Purchase Credit Request Phase. Thus, it can be concluded that all parties have satisfied a secure mutual authentication.

6.2. Making Payment Phase

M1: C O: ID_C, T, ID_M, OI, T, h(OI, SK_CMj), h(ID_C, ID_M, OI, T)

M2: O M: OI, h(OI, SK_CMj), h(OI, SK_COj+1), T

M3: M O: Yes/No, h(Yes, OI, SK_CMj+1), h(Yes, OI)

M4: O TTP: h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI)

M5: TTP O: h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI), h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI), h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI)

M6: O M: h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, OI)

M7: O C: Accept/Reject, Yes, CL_RM, h(Yes, OI, SK_CMj+1), h(OI, SK_MOj+1), h(ID_C, ID_M, OI, T), h(Accept/Reject, OI, CL_RM), h(Yes, IO)

6.2.1. Idealized Form

M1: C O:

M2: O M: OI, (OI, C ), (OI, ), T

M3: M O: Yes/No, (Yes, OI,

M7: O C: Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI,

6.2.2. Initial Assumptions

A1. O|≡ O, A2. M|≡ M,

A3. M|≡ O, A4. O|≡ O,

A5. C|≡ O, A6. C|≡ M,

A7. O|≡ #(T).

6.2.3. The Goals of Analysis

G1. O|≡ID_M, OI, T, (OI, O, G2. M|≡(OI, ),

G3. M|≡OI, (OI, C ), (OI, ), T, G4. O|≡Yes/No, (Yes, OI, .

G5. C|≡(Yes, OI, ), G6. C|≡Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI, .

6.2.4. Details of the Proof

G1. O|≡ID_M, OI, T, (OI, O

O⊲ID_M, OI, T, (OI, O from message M1	1
1, R1: O\|≡O⊲ID_M, OI, T, (OI, O	2
2, R6, A1: O\|≡O has ID_M, OI, T, (OI, O	3
3, R4, A7: O\|≡O⊲(ID_M, OI, T, (OI, ))	4
4: O\|≡ID_M, OI, T, (OI, O	5
G2. M\|≡(OI, )
M⊲(OI, ) from message M1	1
1, R1: M\|≡M⊲(OI, )	2
2, A2: M\|≡M has ()	3
3, R5: M\|≡M has (OI)	4
4: M\|≡(OI, )	5
G3. M\|≡OI, (OI, C ), (OI, ), T
M⊲OI, (OI, C ), (OI, ), T from message M2	1
1, R1: M\|≡M⊲OI, (OI, C ), (OI, ), T	2
2, R6, A3: M\|≡M has OI, (OI, C ), (OI, ), T	3
3, R4, A7: M\|≡M⊲(OI, (OI, C ), (OI, ), T)	4
4: M\|≡OI, (OI, C ), (OI, ), T	5
G4. O\|≡Yes/No, (Yes, OI,
O⊲Yes/No, (Yes, OI, from message M3	1
1, R1: O\|≡O⊲Yes/No, (Yes, OI,	2
2, R6, A4: O\|≡O has Yes/No, (Yes, OI,	3
3: O\|≡O ⊲ (Yes/No, (Yes, OI, ))	4
4: O\|≡Yes/No, (Yes, OI,	5
G5. C\|≡(Yes, OI, )
C⊲(Yes, OI, ) from message M3	1
1, R1: C\|≡C⊲(Yes, OI, )	2
2, R2, A6: C\|≡C has ()	3
3, R5: C\|≡C has (Yes, OI)	4
4: C\|≡(Yes, OI, )	5
G6. C\|≡Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI,
C⊲Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI, from message M4	1
1, R1: C\|≡C⊲Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI,	2
2, R6, A5: C\|≡C has Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI,	3
3: C\|≡C⊲(Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI, ))	4
4: C\|≡Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI,	5

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

7. 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.

Conflicts of Interest

The authors declare that there is no conflict of interest regarding the publication of this paper.

Acknowledgments

This work has been funded by Faculty of Information Science and Technology, Mahanakorn University of Technology, Bangkok, Thailand.

References

N. Saxena and N. S. Chaudhari, “EasySMS: A protocol for end-to-end secure transmission of SMS,” IEEE Transactions on Information Forensics and Security, vol. 9, no. 7, pp. 1157–1168, 2014.
View at: Publisher Site | Google Scholar
M. Toorani and A. A. B. Shirazi, “SSMS - A secure SMS messaging protocol for the m-payment systems,” in Proceedings of the 13th IEEE Symposium on Computers and Communications, ISCC 2008, pp. 700–705, mar, July 2008.
View at: Publisher Site | Google Scholar
N. Saxena and N. S. Chaudhari, “SecureSMS: A secure SMS protocol for VAS and other applications,” The Journal of Systems and Software, vol. 90, no. 1, pp. 138–150, 2014.
View at: Publisher Site | Google Scholar
A. Biryukov, A. Shamir, and D. Wagner, Real time cryptanalysis of A5/1 on a PC, 2007, https://cryptome.org/a51-bsw.htm.
A. Pourali, M. V. Malakooti, and M. H. Yektaie, “A secure SMS model in e-commerce payment using combined AES and ECC encryption algorithms,” Society of Digital Information and Wireless Communication, p. 431, 2014.
View at: Google Scholar
N. R. Kisore and S. Sagi, “A secure SMS protocol for implementing digital cash system,” in Proceedings of the International Conference on Advances in Computing, Communications and Informatics, ICACCI 2015, pp. 1883–1892, ind, August 2015.
View at: Publisher Site | Google Scholar
S. Bojjagani and V. N. Sastry, “SSMBP: A secure SMS-based mobile banking protocol with formal verification,” in Proceedings of the 11th IEEE International Conference on Wireless and Mobile Computing, Networking and Communications, WiMob 2015, pp. 252–259, are, October 2015.
View at: Publisher Site | Google Scholar
H. Rongyu, Z. Guolei, C. Chaowen, X. Hui, Q. Xi, and Q. Zheng, “A PK-SIM card based end-to-end security framework for SMS,” Computer Standards & Interfaces, vol. 31, no. 4, pp. 629–641, 2009.
View at: Publisher Site | Google Scholar
M. Thomas and V. Panchami, “An encryption protocol for end-to-end secure transmission of SMS,” in Proceedings of the IEEE International Conference on Circuit, Power and Computing Technologies, ICCPCT 2015, ind, March 2015.
View at: Publisher Site | Google Scholar
A. Alotaibi and H. Aldabbas, “A review of fair exchange protocols,” International Journal of Computer Networks & Communications, vol. 4, no. 4, 2012.
View at: Google Scholar
A. Paulin and T. Welzer, “A universal system for fair non-repudiable certified e-mail without a trusted third party,” Computers & Security, vol. 32, pp. 207–218, 2013.
View at: Publisher Site | Google Scholar
M. Jakobsson, “Ripping coins for a fair exchange,” Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics): Preface, vol. 921, pp. 220–230, 1995.
View at: Publisher Site | Google Scholar
A. A. Mohammed, “Ownership transfer protocol,” in Proceedings of the Internet Technology and Secured Transactions, 2010.
View at: Google Scholar
R. H. Deng, “Practical protocols for certified electronic mail,” Journal of Network and Systems Management, vol. 4, no. 3, pp. 279–296, 1996.
View at: Publisher Site | Google Scholar
A. Abdullah and H. Aldabbas, “Design and evaluation of a new fair exchange protocol based on an online TTP,” International Journal of Network Security & Its Applications, vol. 4, no. 4, pp. 21–36, 2012.
View at: Google Scholar
J. N. Luo, M. H. Yang, and S.-Y. Huang, “An Unlinkable Anonymous Payment Scheme based on near field communication,” Computers and Electrical Engineering, vol. 49, pp. 198–206, 2016.
View at: Publisher Site | Google Scholar
J. Liu and L. Vigneron, “Design and verification of a non-repudiation protocol based on receiver-side smart card,” IET Information Security, vol. 4, no. 1, pp. 15–29, 2010.
View at: Publisher Site | Google Scholar
W. Fan, H. Shu, E. Fife, and Q. Yan, “An enhanced-security fair E-payment protocol,” in Proceedings of the 2009 WRI World Congress on Computer Science and Information Engineering, CSIE 2009, pp. 516–519, usa, April 2009.
View at: Publisher Site | Google Scholar
M. Ben-Or, O. Goldreich, S. Micali, and R. L. Rivest, “A fair protocol for signing contracts,” Institute of Electrical and Electronics Engineers Transactions on Information Theory, vol. 36, no. 1, pp. 40–46, 1990.
View at: Publisher Site | Google Scholar | MathSciNet
N. Asokan, M. Schunter, and M. Waidner, “Optimistic protocols for fair exchange,” in Proceedings of the 1997 4th ACM Conference on Computer and Communications Security, pp. 6–17, April 1997.
View at: Google Scholar
A. M. Alaraj and M. Munro, “Enforcing honesty in fair exchange protocols,” Advanced Information and Knowledge Processing, vol. 52, pp. 451–479, 2010.
View at: Publisher Site | Google Scholar
A. M. Alaraj, “Purchase of physical products online,” in Proceedings of the 2012 International Conference on Multimedia Computing and Systems (ICMCS), pp. 937–940, Tangiers, Morocco, May 2012.
View at: Publisher Site | Google Scholar
A. M. Alaraj, “Fair certified email protocol,” International Journal of Computer & Technology, vol. 10, no. 1, pp. 1255–1260, 2013.
View at: Google Scholar
R.-J. Hwang and C.-H. Lai, “Provable fair document exchange protocol with transaction privacy for e-commerce,” Symmetry, vol. 7, no. 2, pp. 464–487, 2015.
View at: Publisher Site | Google Scholar | MathSciNet
S. Bojjagani and V. N. Sastry, “A secure end-to-end SMS-based mobile banking protocol,” International Journal of Communication Systems, vol. 30, no. 15, Article ID e3302, pp. 1–19, 2017.
View at: Publisher Site | Google Scholar
C.-L. Chen, H.-Y. Lin, Y.-Y. Chen, and J.-K. Jan, “A fair transaction model in mobile commerce,” in Proceedings of the Signal Processing and Information Technology, pp. 484–489, 2006.
View at: Publisher Site | Google Scholar
M. Burrows, M. Abadi, and R. Needham, “Logic of authentication,” ACM Transactions on Computer Systems, vol. 8, no. 1, pp. 18–36, 1990.
View at: Publisher Site | Google Scholar
C. Thammarat, R. Chokngamwong, C. Techapanupreeda, and S. Kungpisdan, “A secure SMS mobile payment protocol ensuring fair exchange,” in IEE Proc. The 29th Circuit/Systems Computers and Communications, pp. 163–166, Thailand, Phuket, 2014.
View at: Google Scholar
S. Kungpisdan and S. Metheekul, “A secure offline key generation with protection against key compromise,” in Proceedings of the 13th World Multi-Conference on Systemics, Cybernetics and Informatics, WMSCI 2009, Jointly with the 15th International Conference on Information Systems Analysis and Synthesis, ISAS 2009, pp. 63–67, usa, July 2009.
View at: Google Scholar
H. Pagnia and F. C. Gärtner, “On the impossibility of fair exchange without a trusted third party,” Technical Report TUD-BS-1999-02, Darmstadt University of Technology, Department of Computer Science, Darmstadt, Germany, 1999, pp. 1-15.
View at: Google Scholar
O. Dandash, Y. Wang, P. D. Le, and B. Srinivasan, “Fraudulent internet banking payments prevention using dynamic key,” Journal of Networks, vol. 3, no. 1, pp. 25–34, 2008.
View at: Google Scholar
S. Kungpisdan, P. D. Le, and B. Srinivasan, “A limited-used key generation scheme for internet transactions,” Lecture Notes in Computer Science, vol. 3325, 2005.
View at: Google Scholar
H. H. Ngo, X. Wu, P. D. Le, C. Wilson, and B. Srinivasan, “Dynamic key cryptography and applications,” International Journal of Network Security, vol. 10, no. 3, pp. 161–174, 2010.
View at: Google Scholar
S. Kungpisdan, B. Srinivasan, and P. D. Le, “Lightweight mobile credit-card payment protocol,” in Progress in cryptology---{INDOCRYPT} 2003, vol. 2904 of Lecture Notes in Comput. Sci., pp. 295–308, Springer, Berlin, 2003.
View at: Publisher Site | Google Scholar | MathSciNet
A. D. Rubin and R. N. Wright, “Off-line generation of limited-use credit card numbers,” Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics): Preface, vol. 2339, pp. 196–209, 2002.
View at: Google Scholar
C. Cremers, “The scyther tool: verification, falsification, and analysis of security protocols,” in Proceedings of the IEE on Computer Aided Verification, pp. 414–418, Springer, Berlin/Heidelberg, Germany, 2008.
View at: Google Scholar
C. Cremers and M. Sjouke, Operational semantics and verification of security protocols, Springer Science Business Media, 2012.
C. Patsakis, K. Dellios, and M. Bouroche, “Towards a distributed secure in-vehicle communication architecture for modern vehicles,” Computers & Security, vol. 40, pp. 60–74, 2014.
View at: Publisher Site | Google Scholar
Q. Cheng, S. Lu, and J. Ma, “Analysis and improvement of the Internet-Draft IKEv3 protocol,” International Journal of Communication Systems, vol. 30, no. 9, Article ID e3194, 2017.
View at: Publisher Site | Google Scholar
M. Bilal and S. Kang, “Time-assisted authentication protocol,” International Journal of Communication Systems, p. 16, 2017.
View at: Google Scholar
Y. Ma, “NFC communications-based mutual authentication scheme for the internet of things,” International Journal of Network Security, vol. 19, no. 4, pp. 631–638, 2017.
View at: Publisher Site | Google Scholar
N. R. Potlapally, S. Ravi, A. Raghunathan, and N. K. Jha, “A study of the energy consumption characteristics of cryptographic algorithms and security protocols,” IEEE Transactions on Mobile Computing, vol. 5, no. 2, pp. 128–143, 2006.
View at: Publisher Site | Google Scholar
D. Mishra, A. K. Das, A. Chaturvedi, and S. Mukhopadhyay, “A secure password-based authentication and key agreement scheme using smart cards,” Journal of Information Security and Applications, vol. 23, pp. 28–43, 2015.
View at: Publisher Site | Google Scholar
R. Mishra and A. K. Barnwal, “A Privacy Preserving Secure and Efficient Authentication Scheme for Telecare Medical Information Systems,” Journal of Medical Systems, vol. 39, no. 5, 2015.
View at: Publisher Site | Google Scholar
L. Hu, L. Chi, H.-T. Li, W. Yuan, Y. Sun, and J.-F. Chu, “The classic security application in M2M: The authentication scheme of mobile payment,” KSII Transactions on Internet and Information Systems, vol. 6, no. 1, pp. 131–146, 2012.
View at: Publisher Site | Google Scholar
S. Kungpisdan, “Accountability of centralized payment systems: Formal reasoning, protocol design and analysis,” IETE Technical Review, vol. 27, no. 5, pp. 351–364, 2010.
View at: Publisher Site | Google Scholar
Y. Chen, J. Martínez, P. Castillejo, and L. López, “A Privacy Protection User Authentication and Key Agreement Scheme Tailored for the Internet of Things Environment: PriAuth,” Wireless Communications and Mobile Computing, vol. 2017, pp. 1–17, 2017.
View at: Publisher Site | Google Scholar

Copyright

Copyright © 2018 Chalee Thammarat and Werasak Kurutach. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

PDF Download Citation

Download other formats

Order printed copies

Views

1531

Downloads

1141

Citations

O(SN, CL_T, , C ) from message M1	1
1, R1: O\|≡O⊲(SN, CL_T, , C )	2
2, R2, R4, A1, A3: O\|≡O has (, C )	3
3, R5: O\|≡O has (SN, CL_T)	4
4: O\|≡(SN, CL_T, , C )	5
G2. C\|≡(CL_T, , , C )
C⊲(CL_T, , , C ) from message M4	1
1, R1: C\|≡C⊲(CL_T, , , C )	2
2, R2, A2: C\|≡C has (CL_T, , C )	3
3, R4, R5, A4: C\|≡C has ()	4
4: O\|(CL_T, , , C )	5

O⊲ID_M, OI, T, (OI, O from message M1	1
1, R1: O\|≡O⊲ID_M, OI, T, (OI, O	2
2, R6, A1: O\|≡O has ID_M, OI, T, (OI, O	3
3, R4, A7: O\|≡O⊲(ID_M, OI, T, (OI, ))	4
4: O\|≡ID_M, OI, T, (OI, O	5
G2. M\|≡(OI, )
M⊲(OI, ) from message M1	1
1, R1: M\|≡M⊲(OI, )	2
2, A2: M\|≡M has ()	3
3, R5: M\|≡M has (OI)	4
4: M\|≡(OI, )	5
G3. M\|≡OI, (OI, C ), (OI, ), T
M⊲OI, (OI, C ), (OI, ), T from message M2	1
1, R1: M\|≡M⊲OI, (OI, C ), (OI, ), T	2
2, R6, A3: M\|≡M has OI, (OI, C ), (OI, ), T	3
3, R4, A7: M\|≡M⊲(OI, (OI, C ), (OI, ), T)	4
4: M\|≡OI, (OI, C ), (OI, ), T	5
G4. O\|≡Yes/No, (Yes, OI,
O⊲Yes/No, (Yes, OI, from message M3	1
1, R1: O\|≡O⊲Yes/No, (Yes, OI,	2
2, R6, A4: O\|≡O has Yes/No, (Yes, OI,	3
3: O\|≡O ⊲ (Yes/No, (Yes, OI, ))	4
4: O\|≡Yes/No, (Yes, OI,	5
G5. C\|≡(Yes, OI, )
C⊲(Yes, OI, ) from message M3	1
1, R1: C\|≡C⊲(Yes, OI, )	2
2, R2, A6: C\|≡C has ()	3
3, R5: C\|≡C has (Yes, OI)	4
4: C\|≡(Yes, OI, )	5
G6. C\|≡Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI,
C⊲Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI, from message M4	1
1, R1: C\|≡C⊲Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI,	2
2, R6, A5: C\|≡C has Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI,	3
3: C\|≡C⊲(Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI, ))	4
4: C\|≡Accept/Reject, Yes, CL_RM, (Yes, OI, ), (OI,	5

Wireless Communications and Mobile Computing

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

Abstract

1. Introduction

2. Related Works

3. The Proposed Mobile Payment Protocols

3.1. Notations and Assumptions

3.2. The Fairness Model for Internet Transactions

3.3. Background Concept on the Secure Session Key Generation Technique

3.4. Registration Phase

3.5. Purchase Credit Request Phase

3.6. Making Payment Phase

3.7. Dispute Resolution Phase

3.7.1. Purchase Credit Request

3.7.2. Making Payment

4. Discussion

4.1. Security Analysis

4.2. Formal Security Verification of Our Protocols

4.3. Performance Analysis of the Proposed Protocols

5. Analysis of Fairness

5.1. Terms

5.2. Formulae

5.3. Axioms

5.3.1. Comprehensions

5.3.2. Inference Rules

5.3.3. Possessions

5.3.4. Provability

5.4. Initial Assumptions

5.4.1. General Assumptions

5.4.2. Possessions

5.4.3. Shared Secrets

5.4.4. Verifier’s Beliefs

5.4.5. Payment Information

5.4.6. Payment Authorizations

5.5. The Goals of Analysis

5.6. Details of the Proof

6. Security Proof Based on BAN Logic

6.1. Purchase Credit Request Phase

6.1.1. Idealized Form

6.1.2. Initial Assumptions

6.1.3. The Goals of Analysis

6.1.4. Details of the Proof

6.2. Making Payment Phase

6.2.1. Idealized Form

6.2.2. Initial Assumptions

6.2.3. The Goals of Analysis

6.2.4. Details of the Proof

7. Conclusion

Conflicts of Interest

Acknowledgments

References

Copyright