a secure fair exchange for sms-based mobile payment...

22
Research Article A Secure Fair Exchange for SMS-Based Mobile Payment Protocols Based on Symmetric Encryption Algorithms with Formal Verification Chalee Thammarat and Werasak Kurutach Faculty of Information Science and Technology, Mahanakorn University of Technology, 140 Moo 1, Cheumsampan Road, Nong Chok, Bangkok 10530, ailand Correspondence should be addressed to Chalee ammarat; [email protected] Received 30 August 2017; Revised 18 January 2018; Accepted 17 April 2018; Published 5 July 2018 Academic Editor: Javier Aguiar Copyright © 2018 Chalee ammarat and Werasak Kurutach. is 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. 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. erefore, m-payment is a crucial mechanism and needs to be trustworthy from the perspectives of all parties involved. ere are two essential issues that can create trust in a sale transaction based on the m-payment, i.e., fair exchange and information security. ese 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. is kind of payment is simple for purchasers to use. ey 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 proto- cols for mobile payments that satisfy the crucial properties of information security. e secure session key generation technique is employed to accomplish a security requirement. Hindawi Wireless Communications and Mobile Computing Volume 2018, Article ID 6953160, 21 pages https://doi.org/10.1155/2018/6953160

Upload: others

Post on 19-Jul-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Research ArticleA Secure Fair Exchange for SMS-Based Mobile PaymentProtocols Based on Symmetric Encryption Algorithms withFormal Verification

Chalee Thammarat and Werasak Kurutach

Faculty of Information Science and Technology Mahanakorn University of Technology 140 Moo 1 Cheumsampan RoadNong Chok Bangkok 10530 Thailand

Correspondence should be addressed to Chalee Thammarat chalee23gmailcom

Received 30 August 2017 Revised 18 January 2018 Accepted 17 April 2018 Published 5 July 2018

Academic Editor Javier Aguiar

Copyright copy 2018 Chalee Thammarat and Werasak Kurutach This is an open access article distributed under the CreativeCommons Attribution License which permits unrestricted use distribution and reproduction in any medium provided theoriginal work is properly cited

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

1 Introduction

Currently mobile commerce (m-commerce) is one of themost popular methods for buying goods or services onthe Internet It has had a major impact on the growth ofthe world economy as well as improving the quality of lifein the human society One major factor that drives thesuccess of m-commerce is mobile payment (m-payment)which allows the exchange of goods or services and moneybetween a purchaser and a vendor Therefore m-payment isa crucial mechanism and needs to be trustworthy from theperspectives of all parties involved There are two essentialissues that can create trust in a sale transaction based onthe m-payment ie fair exchange and information securityThese will provide all involved parties with the confidencethat no one can take advantage of the others when conductingany sale transaction In addition they can prevent fraudNowadays SMS-based transactional payments are a majormodel of mobile payments This kind of payment is simple

for purchasers to use They can pay for goods or servicesvia a plain text message sent from a mobile phone Howeverthe message is transmitted through the wireless network andhence can be eavesdropped by a malicious person Eventhough theGlobal System forMobile Communication (GSM)uses cryptographic techniques of A51 and A52 betweenthe mobile device and the base station subsystem (BSS) themessages are still vulnerable [1ndash4] During the past few yearsmany researchers have investigated protocols for mobilepayments with fair exchange [1 3 5ndash9] Unfortunately theystill lack some of the important properties of informationsecurity eg mutual authentication nonrepudiation strongfairness (due to no involvement of a trusted third party) andundisclosed information to the trusted third party (if any)

In this paper we review a number of existing techniquesfor ensuring fairness More importantly we propose proto-cols for mobile payments that satisfy the crucial propertiesof information security The secure session key generationtechnique is employed to accomplish a security requirement

HindawiWireless Communications and Mobile ComputingVolume 2018 Article ID 6953160 21 pageshttpsdoiorg10115520186953160

2 Wireless Communications and Mobile Computing

Consequently this results in the lightweight preservationof our protocols Furthermore our approach can be imple-mented on the current SMS infrastructure to retain its easeof use In this method the online TTP (trusted third partyor TTP) model is chosen because the TTP is required tokeep some evidences to be used when a dispute arisesMoreover the online TTP must not be able to access ordisclose information from those evidences in any case or fortheir own benefits In contrast in an offline TTP model theinformation needs to be disclosed to the TTP in order tomake a dispute resolution possible

2 Related Works

Generally there are two types of fairness protocols Onerequires the involvement of a trusted third party (TTP) butthe other does not [10ndash12]The former can be further dividedinto three categories inline [10 13 14] online [7 10 12 15ndash17]and offline [10 11 18ndash24] In our work we will emphasize thefairness protocols that involve the online TTP In this sectionwe will briefly describe previous works related to this topic

A number of mobile payment protocols have been pro-posed [1 3 5ndash9 25] to secure mobile payment based onSMS text messaging Saxena and Chaudhari [1] suggestedEasySMS which offers end-to-end secure communicationthrough SMS between mobile users and is able to preventseveral attacks such as SMS disclosure air modificationreplay attacks man-in-the-middle attacks and imperson-ation attacks This protocol deploys symmetric cryptographyas well as hash functions Pourali et al [5] proposed a secureSMSmodel of e-commerce payment based on Elliptic CurveCryptography (ECC) The authors argue that their modelsatisfies the properties of confidentiality integrity authen-tication and nonrepudiation The paper provides varioustypes of e-payment (electronic payment) business modelswhich are e-payment methods of mobile payment schemesThe model is suitable for SMS-based mobile payment Kisoreand Sagi [6] proposed a secure SMS protocol for a digitalcash system which is a protocol based on ECC with publickey algorithms in the Cryptographic Message Syntax (CMS)key agreement protocol and Advanced Encryption Standard(AES) The proposed digital cash system satisfied confiden-tiality and authentication However the protocols [5 6] lackbilateral authentication and some important properties ofsecurity for example message authentication and recipientauthentication This is because each message is encryptedwith its own public key which cannot verify the sender ofthe message Bojjagani and Sastry [7] proposed SSMBP aunique protocol for SMS which is based on mobile bankingthe payment framework and Elliptic Curve Digital SignatureAlgorithm (ECDSA) used for generating and verifying digi-tal signatures and also for encryption and decryption of SMSThe Elliptic Curve Integrated Encryption Scheme (ECIES) isused to satisfy confidentiality integrity authentication andnonrepudiation This protocol provides secure SMS com-munication between customers and banks through a mobilephone banking application and deploys both symmetric andasymmetric cryptography including hash functions Thereare five parties involved in this protocol a payer a payee

an issuer bank an acquirer bank and a payment gatewayHowever the session key shared between the issuer bankand the payer (SKB) the session key shared between theissuer bank and the payment gateway (SKPG) and the sessionkey shared between the acquirer bank and the paymentgateway (SKAB) need to be transmitted over the networkusing static parameters that could possibly be intercepted byattackers and the protocol is prone to brute force attacksRongyu et al [8] proposed PK-SIM a security frameworkoffering solutions for the development of secure mobilebusiness applications using SMS to provide point-to-pointsecurity between the PK-SIM card and the Secure AccessGateway (SAG) There are parties involved in this protocola PK-SIM card for storing security credentials a SAG forreceiving and sending secure SMS messages a trusted thirdparty the Certification Authority (CA) for providing apublic key certification service and a mobile operator forproviding the communication infrastructure for the SMSBoth symmetric and asymmetric cryptography includinghash functions are deployed in this protocol There arethree subphases the authentication phase the session keyestablishment phase and the communication phase Rongyuet al argue that their framework satisfies the requirementsof authentication integrity and confidentiality Howeverthe session key UAKey (the primary key between the PK-SIM card and the SAG) needs to be transmitted over thenetwork and therefore could possibly be intercepted byattackers In other words it is prone to brute force attacksSaxena and Chaudhari [3] proposed SecureSMS a newsecure and optimal choice for a secure SMS messagingprotocol This protocol provides end-to-end SMS securityand is able to prevent various threats and attacks such asreplay attacks man-in-the-middle attacks SMS spoofingand SMS disclosure The system is based on symmetriccryptography including the hash function The frameworksatisfies authentication confidentiality integrity and nonre-pudiation of the messages There are three parties involvedin this protocol The Mobile Station (MS) sends the SMSand this is carried out by the Authentication Server (AS)with the help of the Certification AuthorityRegistrationAuthority (CARA) The authors argue that their protocolsatisfies message mutual authentication between the MSand AS However within the messages ID MS T1 T3and ExpT are sent in clear text and therefore can beeasily intercepted and modified by an attacker Minta andPanchami [9] proposed an efficient encryption protocol forsecurely transmitting a confidential SMS from one mobilephone to another which serves the cryptographic goals ofconfidentiality authentication and integrity of the messagesThis 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 par-ties Mobile Station 1 (MS1) Mobile Station 2 (MS2) anAuthentication Server (AS) and a Certification Authority(CA) The framework proposed by Bojjagani and Sastry[25] provides end-to-end SMS communication between thecustomer and the bank through a mobile application Themain objective of the framework is to design and developa security framework for SMS banking This framework is

Wireless Communications and Mobile Computing 3

validated using formal methods utilizing a model-checkingtool called Scyther

Unfortunately most of the mobile payment systemsthat have thus far been proposed still lack fairness Forexample some systems allow disclosure of information tothe trusted third party and some do not even involvea trusted third party In addition many researchers haveproposedmobile payment protocols withweaknesses in someareas such as confidentiality integrity nonrepudiation andmutual authentication Mutual authentication can preventboth replay attacks and man-in-the-middle attacks whichis critical for information security This paper introducesmobile payment protocols that enhance fairness and providesecurity properties such as confidentiality integrity nonrepu-diation andmutual authentication In addition the proposedprotocols are lightweight and have improved security sincethey deploy the secure session key generation technique andthe session keys will not be reused

3 The Proposed Mobile Payment Protocols

In this section we apply the fairness model in [28] to mobilepayment protocols to ensure strong fairness Later in thispaper we will show that the proposed protocols satisfy strongfairness Our protocols are composed of two subprotocolsPurchase Credit Request and Making Payment

31 Notations and Assumptions The protocols comprise fourparties a client orC a merchant orM a mobile operator orO(payment gateway) and a trusted third party or TTP Clientsneed to install the proposed software on their mobile devicesThe client who establishes an account with a mobile operatorpays monthly fees

(i) IDA is the identity of A

(ii) DKAB119870119860119861119898119860119861 are the key distribution parametersthat are shared between the parties Readers may findmore details about the key distribution parametersfrom [29] Our protocols used parameters to generatethe secure session key generation technique proposedin [29]

(iii) 119870119860119861 stands for a long-term key

(iv) DKAB stands for a distributed key

(v) 119898119860119861 is a random number It is utilized to indicate thenumber of keys that will be produced

(vi) SKABj where j = 1 m are the session keys sharedbetween party 119860 and party B

(vii) h(M SKABj) is a Message Authentication Code(MAC) of a message119872 and a key SKABj

(viii) h(M) is a hash value of a messageM

(ix) 119872119878119870119860119861119895 is a symmetrically encrypted message of amessage119872 with a key SKABj

(x) CLT is a credit limit up to which the client is allowedto purchase goods or services

(xi) SN is a serial number for a top-up cash card purchasedoffline which infers the credit limit in the clientrsquosaccount

(xii) CLRM is the remaining credit in the clientrsquos account

(xiii) OI = 119879119868119863 119875119903119894119888119890 119874119863 TID is Transaction ID Priceis the price of goods or services and OD is an orderdescription containing details of the goods or servicespurchased

The mobile operator establishes a Transport Layer Secu-rity (TLS) session and shares this KOTTP DKOTTP mOTTPwith TTP Both the mobile operator and TTP create a setof session keys SKOTTPj by using the secure session keygeneration technique proposed in [29] where j = 1 m while implementing the system The proposed protocolsassume that the session keys between parties are the same

32The FairnessModel for Internet Transactions Thammaratet al [28] proposed a fairnessmodel for Internet transactionsThe model supports a mobile payment protocol This modelstill lacks some of the conditions to fully ensure fairnessTherefore we extend the proposed model in [28] to completethe fairness protocols The symbolic notations and modaloperators can be defined as follows

Let 119878 denote a payment system defined as S = 119862119872 119875119866where 119862 is a client who buys goods or services M is amerchant and PG is a payment gateway which acts as thefinancial institution for both 119862 and 119872 In the paymentsystem C acts as the payer and 119872 acts as the payee Inaddition let 119881 be a verifier an external party not involvedin a transaction but trusted by all parties and let TTP denotea trusted third party TTP is not involved in the transactionitself but keeps all transaction data for later verification Rdenotes any party

(i) P authorized X the party 119875 has authorization toperform an action X

(ii) P CanProve X to R the party 119875 is able to prove to theparty 119877 that the statement 119883 is true without revealing anyinformation which is considered to be secret to R

(iii) Payment-order(C M) is the interaction between theclient and the merchant when the client requests to purchasegoods or services from the merchant

(iv) Debit(C PG) is the interaction between the paymentgateway and the client regarding the deduction of the pay-ment token requested by the client from the clientrsquos account

(v) Credit(M PG) is the interaction between the paymentgateway and the merchant in order to transfer the paymenttoken to the merchant account

(vi) Log(C TTP) is the interaction between TTP and theclient enabling TTP to keep all the transactions occurringbetween the client and related parties and send them to theclient

We define a new operator called ldquosatisfiesrdquo which refers tothe situation where a party satisfies the result given at the endof the transaction For example ldquoC satisfies payment-order(CM)rdquo means that the client 119862 has satisfied the results of thetransaction occurring between the client and the merchant

4 Wireless Communications and Mobile Computing

Table 1 Advantages and disadvantages of the types of fairness

Type of Fairness Advantage Disadvantage

No Fairness (i) no cost of TTP(i) very high number of messages(ii) need for reliable network(iii) unable to have dispute resolution

Weak Fairness (i) low number of messages (i) need for reliable network(ii) full TTP

Strong Fairness (i) semi-TTP(ii) no need for reliable network

(i) high number of messages(ii) cost of TTP

The conditions of fairness are as follows Strong fairness(1) TTP is involved (2) There is no information disclosureto TTP Weak fairness (1) TTP is involved (2) There isinformation disclosure to TTP No fairness (1) TTP is notinvolved The details of each condition of fairness can beexplained as follows

(i) TTP is involved TTP keeps all the transactions andprovides the transaction occurring between the parties asevidence when a dispute arises

(ii) TTP is not involved there is no TTP to keep alltransactions and no evidence can be sent to the partiesWhen a dispute arises parties cannot have dispute resolutionIt is not possible to ensure fairness that is not strongly aninvolvement of TTP [21 30]

(iii) Information disclosure to TTP TTP can read alltransactions occurring between the two parties TTPmay sellthe information about parties to the competitors

(iv) No information disclosure to TTP there is no TTPinvolvedTTP cannot read all transactions occurring betweenparties and therefore cannot sell the information aboutparties to the competitors

Table 1 shows the advantages and disadvantages of thetypes of fairness Strong fairness has more advantages thanthe other types for example semi-TTP (semitrusted thirdparty) and it does not need a reliable network In this paperwe will apply Thammaratrsquos fairness model for Internet trans-actions to existing SMS mobile payment protocols for strongfairness Note that a semi-TTP is one that can misbehaveon its own but will not collude with any of the participatingparties

Clientrsquos FairnessThe following requirementsmust be satisfiedfrom the clientrsquos 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 V997888rarr C satisfies payment-order(C M TTP)In each clientrsquos opinion the client will satisfy the trans-

actions only if heshe gets both a payment-order responsefrom the merchant and a debit response from the paymentgateway However the responses must be from the previoustransaction made by the client All requests are sent to thetrusted third party

Merchantrsquos Fairness For a transaction to be satisfactory inthe merchantrsquos opinion the following requirements must besatisfied

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 V997888rarrM satisfies credit (M PG TTP)It can be seen from the above statements that the

merchant will satisfy a transaction if heshe has delivered orcommitted to deliver goods or services to clients as a resultof receiving a payment-order request from the client Thepayment has to be processed by the payment gateway Thepayment gateway must transfer the amount requested by themerchant to the account of themerchant prior to the deliveryof goods or services to the client

Payment Gatewayrsquos Fairness For a transaction to be sat-isfactory in the payment gatewayrsquos opinion the followingrequirements 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 V997888rarr 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 andmerchant Specifically the payment gateway must performactions according to the debit and credit requests made byboth the client and the merchant The payment gatewaytransfers or commits to deduct the amount requested by theclient and transfer the amount requested by the merchant tothe account of the merchant

33 Background Concept on the Secure Session Key GenerationTechnique In this section we will explain the concept of thesecure session key generation technique that is used in a phaseof our proposed protocols The topics that are extensivelydiscussed in symmetric encryptions are the secure sessionkey generation techniques Many researchers have presenteda secure session key generation technique used in their own

Wireless Communications and Mobile Computing 5

Session key3+D D = 1 -

Intermediate key generationRound n

Intermediate key generationRound 1

Preference key generation+C = B(+C-1 $+)

)+1D = B(=IH=(+-C>) )+

1D-1)

)+HD = B(=IH=()+H-1

-C>) )+HD-1)

Figure 1 Session key generator

papers [29 31ndash35] Among all the mentioned approaches[29] proposed a secure session key generation technique thatprevents key compromise attacks Moreover with the securesession key generation technique the parties do not need totransmit a key over the network In our paper we use [29]in introducing our protocols The methodology of [29] isdemonstrated below

Let us assume that party A and party B share 119870119860119861 DKm where 119870119860119861 stands for a long-term key DK stands fora distributed key and 119898 is a random number m is utilizedto indicate the number of keys that will be produced Theconc(M1 M2 M3) shows the concatenation of each of themessages M1 M2 and M3 respectively The secure sessionkey generation technique process is shown in Figure 1

After sharing 119870119860119861 DK m party A and party B create aset of preference keys 119870119894 where i = 1 m as follows 119870119894 =h(119870119894-1 DK) where1198700 =119870119860119861The set of119870119894will be applied as anorigin to invigorate session keys K and DK can be removedfrom the system

Next party A and party B generate sets of intermediatekeys to increase the difficulty for cryptanalysis Moreoverthis makes it more difficult to find the preference key ifthe session key is compromised In each round a new setof intermediate keys is produced Note that the higher thenumber of rounds performed the greater the security ofthe system The intermediate key generation is performedas follows 119868119870119909119895 = ℎ(119888119900119899119888(119868119870119909-1119872119894119889) 119868119870

119909119895-1) where 119909

specifies the number of rounds and j specifies the number of

intermediate keys that are generated j = 1 m 119868119870119909-1119872119894119889stands for the set of 119868119870119909-11198721198941198891 119868119870

119909-11198721198941198892 119868119870

119909-11198721198941198893

1198681198701199091198721198941198891 = 119898119894119889(1198681198701199091 119868119870119909119903119898) and 119903119898 is the remaining

number of intermediate keys in the set of 119868119870119909119895 1198681198701199091198721198941198892 =

119898119894119889(1198681198701199091198721198941198891 119868119870119909119903119898) 1198681198701199091198721198941198893 = 119898119894119889(1198681198701199091 119868119870

1199091198721198941198892)

11986811987011198721198941198891 = 1198701198721198941198891 11986811987011198721198941198891 = 1198701198721198941198892 and 119868119870

11198721198941198891 = 1198701198721198941198893

The generation of11987011987211989411988911198701198721198941198892 and1198701198721198941198893 is the same as thatof 1198681198701199091198721198941198891 1198681198701199091198721198941198892 and 1198681198701199091198721198941198893 respectively 119868119870119909119895-1 = 120593The output of the last round of intermediate key generationis considered as session keys SKj where j = 1 m whichis shown below 1198681198701198991 = 1198781198701 119868119870

1198992 = 1198781198702 119868119870

119899119898 = 119878119870119898

Party A and party B can then use SKj as a credential tosecure transactions as say an encryption key or as an inputto Message Authentication Codes

It can be obviously seen that the session key is createdpurely offline Each party can produce a set of session keysused to secure communication among themselves with norequirements to exchange credentials through the networkas a new session key is not transferred over the network

34 Registration Phase It is assumed that mobile deviceshave the software based on installation of our protocols Oncethe software is loaded the client needs to log on to thepayment system via a secure channel eg TLS (TransportLayer Security) The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119874DKCO 119898119862119874 with the mobile operator The client and themobile operator create a set of session keys SKCOj by usingthe secure session key generation technique proposed in [29]where j = 1 m

(2)The client establishes a TLS session and shares KCTTPDKCTTP mCTTP with TTP The client and TTP create a set ofsession keys SKCTTPj using the secure session key generationtechnique proposed in [29] where j = 1 m

35 Purchase Credit Request Phase In this section before theclient pays for goods or services the client purchases a top-up cash card The client runs the client software from hisherdevice Next he or she fills in the serial number of the top-upcash card and sends the following to the mobile operator

M1 C997888rarrO 119868119863119862 SN1198791 h(SN CLT1198791 SKCOj) h(119868119863119862SN CLT 1198791)119878119870119862119879119879119875119895

M2 O 997888rarr TTP h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 h(CLT1198791 1198792)119878119870119874119879119879119875119895

M3 TTP 997888rarr O h(IDC SN CLT 1198791) h(CLT 11987911198792)119878119870119862119879119879119875119895+1 h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1

M4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SNCLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1

In message M1 the client sends message IDC SN 1198791h(SN CLT 1198791 SKCOj) h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 to themobile operator The message h(SN CLT 1198791 SKCOj) is con-sidered as Message Authentication Code (MAC) which is anauthentication token between the client and the mobile oper-atorMoreover in order to guarantee information correctnessand to defend against erroneous information alteration ordestruction the message h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 willbe transmitted to TTP via the mobile operator Note that 1198791

6 Wireless Communications and Mobile Computing

Table 2 Symbols and abbreviations

Symbol Definition Bits

IDMS1IDMS2IMSI International Mobile Subscriber Identity ofMobile station 80

MACH Message Authentication CodeHash function 160ReqNoSeq Request number 8DK Delegation key 128Order msg Product order 160PriceP Cost of product 64

Withdraw Req Msg Withdraw Resp Msg The customer pays the desired price from hisbank 64

Ack A validation message to the customer 64FS Financial server identification 128Name Name of payer 160NationalID National Identification 104RandomPublicKey The ephemeral public key 128PayeeMobNo Mobile phone number of payee 80Value Digital currency 80IDPRIDPEIDCIDM Identification of Payer PayeeClientMerchant 80Payee Id Identification of Payee 80BI Bank information 128Amt Amount in payerrsquos bank account 64SKBSKPGSKIBSKPGIBSKPGABSKCOSKCTTPSKOTTPSKMTTPSKCMSKMOSKABKPasskeyUAKey

Session Key 128

TSPGTSIBTSBTSPR TT1T2T3T4T5 Timestamp 80NPGNIBNPRNB Nonce 128Payment Notify Payment acknowledgment 128PIPR Payment Information of payer 128TID Transaction ID 128ExpTExpiryKeyExpiry Expiry of primary key 64NSNC Random number 128CertSAG Certificate of Security Access Gateway 40ID ME Mobile phone Number 80CME Certificate of mobile phone 40SN Serial number of the top-up cash card 112CLT Credit limit 40CLRM Remaining credits 40OIOrder Message Order information 160

(YesNo) Purchase credit requestMessage status ofmerchant verifies the goods or services 24

(AcceptReject)Req Msg Payment status 48

denotes the timestamp for the time when the purchase creditis requested and to prevent a replay attack

In message M2 upon receiving this message from theclient the mobile operator sends the message h(IDC SNCLT 1198791)119878119870119862119879119879119875119895 h(CLT 1198791 1198792)119878119870119874119879119879119875119895 to TTP

In message M3 TTP decrypts this message with SKCTTPjand SKOTTPj and keeps the hash value TTP encrypts the hashvalue of h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 with

SKCTTPj+1and encrypts the hash value of h(IDC SN CLT1198791)h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1 with SKOTTPj+1 Then TTP sends allthe messages to the mobile operator Note that 1198792 denotes thetimestamp when the purchase credit is sent to a client and toprevent a replay attack

In message M4 the mobile operator generates messageh(CLT 1198791 1198792 SKCOj+1) which is an authentication tokenbetween the client and the mobile operator Moreover this

Wireless Communications and Mobile Computing 7

Table 3 Cryptographic operation functions

Functions DefinitionDK Encryption with delegation KeySK Encryption with symmetric key encryptionPub Encryption with asymmetric key encryptionf1 Cryptographic function to generate DKf2 Message Authentication Code functionf3 Hash function

Table 4 Message length of our protocols

Message Purchase Credit (Bytes) Making Payment(Bytes)

M1 96 126M2 64 80M3 96 64M4 88 96M5 - 192M6 - 64M7 - 112Total (Bytes) 344 734

message is created in order to guarantee information correct-ness and to defend against erroneous information alterationor destruction Then the mobile operator sends messageh(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 to the client

In the above messages the client supplies the serialnumber of the top-up cash card together with the requestedcredit limit to themobile operatorMobile operators can inferthe credit limit from the serial number given that the serialnumber is from a prepaid cash card Note that serial numberscan also track the credit limit up to which the client is allowedto buy goods or services from the mobile operator Notethat an attacker cannot modify the serial number when theserial number is transmitted in clear text as it is key-hashedin h(SN CLT 1198791 SKCOj) which is a MAC with SKCOj thatis shared between the client and the mobile operator Afterreceiving the demand from the client the mobile operatoradds the credit limit value to the clientrsquos account and sendsa message to the client The mobile operator acknowledgesthe increment of the clientrsquos credit limit During this phasethe client utilizes a top-up cash card in case they do not haveenough credit to make the payment phase

36Making Payment Phase At the beginning of the protocolthe client and the merchant need to establish accounts withtheir mobile operator The mobile operator will deduct acertain amount of value that is purchased by the client whenheshe opens the account There are two major functions onthe clientrsquos side application to operate searching and MakingPayment for goods or services The merchant is the sellerof the goods or services on a mobile portal operated by themobile operator The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119872DKCM119898119862119872with themerchantThe client and themerchant

create a set of session keys SKCMj by using the secure sessionkey generation technique proposed in [29] where j = 1 m

(2) The merchant establishes a TLS session and shares119870119872119874 DKMO119898119872119874 with the mobile operator The merchantand the mobile operator create a set of session keys SKMOjusing the secure session key generation technique proposedin [29] where j = 1 m

(3) The merchant establishes a TLS session and sharesKMTTP DKMTTP mMTTP with TTP They both establish aset of session keys SKMTTPj using the secure session keygeneration technique proposed in [29] where j = 1 m

(4) The client browses lists of goods or services via theapplication on his or her device When the goods or serviceshave been added to the cart the client can make a paymentby the protocol described below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895Otherwise the mobile operator terminates the clientrsquos

requestM5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

In the case of message M1 the client sends messageIDC T IDM OI T h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OIT)119878119870119862119879119879119875119895 to the mobile operator The message IDM OIT h(OI SKCMj)119878119870119862119874119895 is encrypted with SKCOj which isthe session key shared between the client and the mobileoperator for the mobile operation to verify authenticity ofthe client It can be noted that the mobile operator doesnot know the session key SKCMj in order to construct themessage h(OI SKCMj) since it cannot generate thismessage byitself This message h(OI SKCMj) is considered as a MessageAuthentication Code (MAC) which is used to guaranteeinformation correctness and to defend against erroneousinformation alteration or destruction Moreover it enablesthe merchant to verify authenticity of the client The messageh(IDC IDM OI T)119878119870119862119879119879119875119895 will be transmitted to TTP viathe mobile operator It should be noted that 119879 denotes thetimestamp when the payment is requested and to prevent areplay attack

In the case of message M2 upon receiving the messagefrom the client the mobile operator sends message OI h(OISKCMj) h(OI SKCOj+1) T119878119870119872119874119895 to the merchant to verify theauthenticity of the mobile operator The hash value of h(OISKCMj) indicates that the mobile operator does not know thesession key SKCMj that is used to construct the message h(OISKCMj) since it cannot generate this message by itself

8 Wireless Communications and Mobile Computing

Table 5 SMS overhead of our protocols

Session SMS OverheadBytes 7-Bit ASCII (160 Byte) 8-Bit ASCII (140 Byte)

Purchase CreditM1 96 60 6875M4 88 55 6285

Making PaymentM1 126 7875 90M7 112 70 80

Table 6 Comparison of cryptographic operations

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Making PaymentSymmetric Encryption 6 - - 3 2 5 9 3 4 10Asymmetric Encryption - 4 3 4 4 - - 5 - -Message Authentication Code 3 - - 3 - - - 2 2 4Hash Function - - - - 4 2 1 - 2 3Number of Messages 9 6 5 6 6 7 9 6 4 7Number of Parties 4 4 2 5 3 3 4 5 3 4

Table 7 Comparison of energy consumption

AES (121 120583Jbyte) RSA (5465 120583Jbyte) HMAC (116 120583Jbyte) SHA1 (076 120583Jbyte) Total (120583Jbyte)[1] 726 0 348 0 1074[5] 0 2186 0 0 2186[6] 0 16395 0 0 16395[7] 363 2186 348 0 219311[8] 242 2186 0 304 219146[3] 605 0 0 152 757[9] 1089 0 0 076 1165[25] 363 27325 232 0 27385Purchase Credit 484 0 232 152 868Making Payment 121 0 464 228 1902

Table 8 Communication complexity

Protocol Communication cost (bits)

[1] (1)+(2)+(3)+(4)+(5)+(6)+(7)+(8)+(9)=(80+80+160+24)+(80+80+80+80+160+160)+(80+80+80)+(80)+(80+160+64)+(80+24)+(80+24+64+128)+(80)+(24+80)=2192lowastn

[5] (1)+(2)+(3)+(4)+(5)+(6)= (160)+(64+160+80)+(64+48)+(64)+(64)+(64)=768lowastn[6] (1)+(2)+(3)+(4)+(5)=(128)+(160+80+104+160+64+128)+(128)+(128)+(80+80+128+128)=1496lowastn

[7] (1)+(2)+(3)+(4)+(5)+(6)=80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)+(80+64+128+160)+(128+64+80+128+160)+(128+80+128)=3728lowastn

[8] (1)+(2)+(3)+(4)+(5)= (40+80+128+24)+(80)+(40+160)+(128+128+64+160)+(128)=1160lowastn[3] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn[9] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn

[25](1)+(2)+(3)+(4)+(5)+(6)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)

+(128+80+128+128+80+128)+(160+128+128+128+128+80)+(160+128+128+128+128+80)+(128+80+128)=4592lowastn

MakingPayment

(1)+(2)+(3)+(4)+(5)+(6)+(7)=80+80+80+160+80+160+160)+(160+160+160+80)+(24+160+160)+(160+160+160)+(160+160+160+160+160+160+160+160+160)+(160+160+160)

+(48+24+40+160+160+160+160+160)=5016lowastn

Wireless Communications and Mobile Computing 9

Table 9 Computational complexity

Protocol Computational cost[1] f2 f2 SK SK f2 f1 DK f1 SK SK DK=11lowastn[5] Pub Pub Pub Pub=4lowastn[6] Pub f3 Pub SK=4lowastn[7] Pub Pub Pub Pub f2 SK f2 SK f2 SK=10lowastn[8] f3 Pub f3 Pub f2 Pub Pub SK=8lowastn[3] f2 SK SK f1 f2 f1 DK=7lowastn[9] f2 SK SK f1 f2 f1 DK=7lowastn

[25] Pub Pub Pub Pub Pub SK f2 SK f2SK=10lowastn

MakingPayment

f2 SK f3 SK f3 SK f2 SK f3 SK f3 SK SKSK SK f2 SK=17lowastn

In the case of message M3 after receiving the messagefrom the mobile operator the merchant verifies the goodsor services If these are valid a Yes message will be sent tothe mobile operator but if they are invalid a No messagewill be sent to the mobile operator and then the mobileoperator will terminate the clientrsquos request The merchantthen sends the message YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1h(Yes OI)119878119870119872119879119879119875119895 to the mobile operator The messagethat contains YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1 is for themobile operator to verify the authenticity of the merchantIt should be noted that the mobile operator does not knowthe session key SKCMj+1 that is used to construct the messageh(Yes OI SKCMj+1) since it cannot generate this message byitself This message contains h(YesNo OI SKCMj+1) in orderto guarantee information correctness and to defend againsterroneous information alteration or destructionThemessageh(Yes OI)119878119870119872119879119879119875119895 will be transmitted to TTP via the mobileoperator

In the case of message M4 upon receiving this messagefrom the merchant the mobile operator checks the creditbalance and compares it with the requested amount If theclient has enough credit the mobile operator will reply withan Accept message to the client If not the mobile operatorwill reply with a Reject message and then the client has toreturn to the Purchase Credit Request Phase The mobileoperator then sends message h(IDC IDM OI T)119878119870119862119879119879119875119895h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895 toTTP

In the case of message M5 after receiving the mes-sage from the mobile operator TTP decrypts the messageh(IDC IDM OI T)119878119870119862119879119879119875119895 with SKCTTPj h(AcceptRejectOI CLRM)119878119870119874119879119879119875119895 with SKOTTPj and h(Yes OI)119878119870119872119879119879119875119895with SKMTTPj and it keeps the decrypted message toitself Then TTP encrypts the message h(IDC IDM OIT) h(AcceptReject OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 withSKCTTPj+1 h(IDC IDM OI T) h(AcceptReject OI CLRM)h(Yes OI)119878119870119874119879119879119875119895+1 and encrypts themessage with SKOTTPj+1and h(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119872119879119879119875119895+1TTP also encrypts themessage with SKMTTPj+1and sends all the messages to the mobile operator

In the case of message M6 the mobile operator for-wards the message h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1 which is encrypted by TTPwithSKMTTPj+1 to the merchant

In the case of message M7 the mobile operator encryptsmessage one AcceptReject Yes CLRM h(Yes OI SKCMj+1)h(OI SKMOj+1)119878119870119862119874119895+1 with SK119862119874119895+1 while the messageh(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119862119879119879119875119895+1 is encrypted by TTP with SK119862119879119879119875119895+1 to theclient The message that contains AcceptReject Yes CLRMh(YesNo OI SKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 is for the clientto verify the authenticity of themobile operator It can be seenthat the mobile operator cannot deny that the message hasoriginated from himher because only the mobile operatorpossesses both SKMOj +1 and SKCOj+1 This means that themobile operator is the only one that can generate thismessage The hash value of h(YesNo OI SKCMj+1) notes thatthe mobile operator does not know the session key SK119862119872119895+1that is used to construct the message h(Yes OI SKCMj+1) andthe client to verify the authenticity of the merchant since itcannot generate this message by itself

37 Dispute Resolution Phase After the transaction is com-plete if the client is not satisfied with the transaction heshecan request a dispute resolution with the verifier The disputeresolution protocols are composed of two subprotocolsPurchase Credit Request Phase and Making Payment PhaseConsider the protocols below

371 Purchase Credit Request Theclient sends the hash valueh(IDC SN CLT 1198791) h(CLT 1198791 1198792) of the transaction to theverifier Upon receiving the hash value from the client theverifier sends the requested hash value ofTTP After receivingthe hash value fromTTP the verifier compares the hash valuefrom the client with a hash value from TTP If the hash valuesdo not match the verifier rejects the clientrsquos request if notthe verifier sends a notification of dispute resolution to themobile operator to transfer the amount to the clientrsquos accountNote that the verifier stands for the external party and is aparty that is not relevant to the particular transaction

372 Making Payment The client sends the hash valueh(IDC IDM OI T) h (OI CLRM) h(YesNo OI) of thetransaction to the verifier Upon receiving the hash valuefrom the client the verifier sends the requested hash valueof TTP After receiving the hash value from TTP the verifiercompares the hash value from the client with a hash valuefrom TTP If the hash values do not match the verifier rejectsthe clientrsquos request if not the verifier sends a notificationof dispute resolution to the mobile operator to transfer theamount to the clientrsquos account and sends notification to themerchant Note that the verifier stands for the external partyand is a party that is not relevant to the particular transaction

It is obvious that in the Purchase Credit Request Phase(Section 35) and theMaking Payment Phase (Section 36) allmessages received by the TTP are only the hash values of thetransactional data Therefore it is not possible for the TTP to

10 Wireless Communications and Mobile Computing

Table 10 Storage complexity

Protocol Storage cost[1] (1)+(2)+(3)+(4)=(80+80+160+24)+(80+160+64)+(80+24=104)+(24+80)=856lowastn[5] (1)+(2)+(3)+(4)=(160)+(64+160+80)+(64+48)+(64)=640lowastn[6] (1)+(2)+(3)= (128)+(160+80+104+160+64+128)+(80+80+128+128)=1240lowastn[7] (1)+(2)+(3)=(80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)=2400lowastn[8] (1)+(2)+(3)=(40+80+128+24)+(128+128+64+160)+(128)=880lowastn[3] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn[9] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn

[25] (1)+(2)+(3)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)+(128+80+128+128+80+128)=2752lowastn

MakingPayment (1)+(2)=(80+80+80+160+80+160+160)+(48+24+40+160+160+160+160+160)=1712lowastn

Table 11 Comparison of mobile payment protocols

Protocol Type of Fairness Uses TTP TTP Type[1] No Fairness No Without TTP[5] No Fairness No Without TTP[6] No Fairness No Without TTP[7] No Fairness No Without TTP[8] No Fairness No Without TTP[3] No Fairness No Without TTP[9] Weak Fairness Yes Online[25] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

accessmeaningful information of the transactionThismakesour protocols have strong fairness

4 Discussion

41 Security Analysis (1) Brute force attacks for the comple-tion of a transaction of our protocols the session keys changeevery time and are not reused therefore it is difficult for theattacker to find the correct session key that is shared betweenparties In addition according to [29] a brute force attackis difficult to complete by applying an offline key generationtechnique

(2) Replay attack prevention the attacker intersects themessage and resends an old message Our protocols are usedonly once with a fresh timestamp so a replay attack can beprevented and is difficult to accomplish For further detailsabout this technique the reader is referred to [29]

(3) Message integrity the integrity of the message is themost important security property that any party can ensureso that the message guarantees information correctness andis defended against erroneous information alteration ordestruction during the transmission With our protocolseach message comprises a Message Authentication Code(MAC) value that ensures the recipient of the message andthe same recent key can be used to generate a newMACThereceived MAC is compared with the calculated MAC

(4) Mutual authentication this is used to check who theoriginator and the receiver of a message are Our protocolsdeployMACs and symmetric cryptographic operations Onlythe originator and the receiver who share the same key will beable to encrypt and decrypt their messages As a result of ourprotocols eachmessage can be used to identify the originatorand the receiver so that the client the merchant and themobile operator ensure mutual authentication Consider themessage below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client and the mobile operatorshare the session key SKCOj but the mobile operator cannotgenerate thismessage by himself or herself because themobileoperator cannot generate h(OI SKCMj) as the session keySKCMj is shared only between the merchant and the clientOnly the session keys SKCMj and SKCOj are known by theclient therefore guaranteeing that the client generated thismessage

(5)Man-in-the-middle attacks an attacker cannot imper-sonate a party by intercepting message passes in theseprotocolsWith the use of limited-use session keys and propercryptographic operations no confidential information isrevealed and the reuse of authentication information islimited In addition the session keys used in our protocolsare changed constantly using strong encryption techniques

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 2: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

2 Wireless Communications and Mobile Computing

Consequently this results in the lightweight preservationof our protocols Furthermore our approach can be imple-mented on the current SMS infrastructure to retain its easeof use In this method the online TTP (trusted third partyor TTP) model is chosen because the TTP is required tokeep some evidences to be used when a dispute arisesMoreover the online TTP must not be able to access ordisclose information from those evidences in any case or fortheir own benefits In contrast in an offline TTP model theinformation needs to be disclosed to the TTP in order tomake a dispute resolution possible

2 Related Works

Generally there are two types of fairness protocols Onerequires the involvement of a trusted third party (TTP) butthe other does not [10ndash12]The former can be further dividedinto three categories inline [10 13 14] online [7 10 12 15ndash17]and offline [10 11 18ndash24] In our work we will emphasize thefairness protocols that involve the online TTP In this sectionwe will briefly describe previous works related to this topic

A number of mobile payment protocols have been pro-posed [1 3 5ndash9 25] to secure mobile payment based onSMS text messaging Saxena and Chaudhari [1] suggestedEasySMS which offers end-to-end secure communicationthrough SMS between mobile users and is able to preventseveral attacks such as SMS disclosure air modificationreplay attacks man-in-the-middle attacks and imperson-ation attacks This protocol deploys symmetric cryptographyas well as hash functions Pourali et al [5] proposed a secureSMSmodel of e-commerce payment based on Elliptic CurveCryptography (ECC) The authors argue that their modelsatisfies the properties of confidentiality integrity authen-tication and nonrepudiation The paper provides varioustypes of e-payment (electronic payment) business modelswhich are e-payment methods of mobile payment schemesThe model is suitable for SMS-based mobile payment Kisoreand Sagi [6] proposed a secure SMS protocol for a digitalcash system which is a protocol based on ECC with publickey algorithms in the Cryptographic Message Syntax (CMS)key agreement protocol and Advanced Encryption Standard(AES) The proposed digital cash system satisfied confiden-tiality and authentication However the protocols [5 6] lackbilateral authentication and some important properties ofsecurity for example message authentication and recipientauthentication This is because each message is encryptedwith its own public key which cannot verify the sender ofthe message Bojjagani and Sastry [7] proposed SSMBP aunique protocol for SMS which is based on mobile bankingthe payment framework and Elliptic Curve Digital SignatureAlgorithm (ECDSA) used for generating and verifying digi-tal signatures and also for encryption and decryption of SMSThe Elliptic Curve Integrated Encryption Scheme (ECIES) isused to satisfy confidentiality integrity authentication andnonrepudiation This protocol provides secure SMS com-munication between customers and banks through a mobilephone banking application and deploys both symmetric andasymmetric cryptography including hash functions Thereare five parties involved in this protocol a payer a payee

an issuer bank an acquirer bank and a payment gatewayHowever the session key shared between the issuer bankand the payer (SKB) the session key shared between theissuer bank and the payment gateway (SKPG) and the sessionkey shared between the acquirer bank and the paymentgateway (SKAB) need to be transmitted over the networkusing static parameters that could possibly be intercepted byattackers and the protocol is prone to brute force attacksRongyu et al [8] proposed PK-SIM a security frameworkoffering solutions for the development of secure mobilebusiness applications using SMS to provide point-to-pointsecurity between the PK-SIM card and the Secure AccessGateway (SAG) There are parties involved in this protocola PK-SIM card for storing security credentials a SAG forreceiving and sending secure SMS messages a trusted thirdparty the Certification Authority (CA) for providing apublic key certification service and a mobile operator forproviding the communication infrastructure for the SMSBoth symmetric and asymmetric cryptography includinghash functions are deployed in this protocol There arethree subphases the authentication phase the session keyestablishment phase and the communication phase Rongyuet al argue that their framework satisfies the requirementsof authentication integrity and confidentiality Howeverthe session key UAKey (the primary key between the PK-SIM card and the SAG) needs to be transmitted over thenetwork and therefore could possibly be intercepted byattackers In other words it is prone to brute force attacksSaxena and Chaudhari [3] proposed SecureSMS a newsecure and optimal choice for a secure SMS messagingprotocol This protocol provides end-to-end SMS securityand is able to prevent various threats and attacks such asreplay attacks man-in-the-middle attacks SMS spoofingand SMS disclosure The system is based on symmetriccryptography including the hash function The frameworksatisfies authentication confidentiality integrity and nonre-pudiation of the messages There are three parties involvedin this protocol The Mobile Station (MS) sends the SMSand this is carried out by the Authentication Server (AS)with the help of the Certification AuthorityRegistrationAuthority (CARA) The authors argue that their protocolsatisfies message mutual authentication between the MSand AS However within the messages ID MS T1 T3and ExpT are sent in clear text and therefore can beeasily intercepted and modified by an attacker Minta andPanchami [9] proposed an efficient encryption protocol forsecurely transmitting a confidential SMS from one mobilephone to another which serves the cryptographic goals ofconfidentiality authentication and integrity of the messagesThis 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 par-ties Mobile Station 1 (MS1) Mobile Station 2 (MS2) anAuthentication Server (AS) and a Certification Authority(CA) The framework proposed by Bojjagani and Sastry[25] provides end-to-end SMS communication between thecustomer and the bank through a mobile application Themain objective of the framework is to design and developa security framework for SMS banking This framework is

Wireless Communications and Mobile Computing 3

validated using formal methods utilizing a model-checkingtool called Scyther

Unfortunately most of the mobile payment systemsthat have thus far been proposed still lack fairness Forexample some systems allow disclosure of information tothe trusted third party and some do not even involvea trusted third party In addition many researchers haveproposedmobile payment protocols withweaknesses in someareas such as confidentiality integrity nonrepudiation andmutual authentication Mutual authentication can preventboth replay attacks and man-in-the-middle attacks whichis critical for information security This paper introducesmobile payment protocols that enhance fairness and providesecurity properties such as confidentiality integrity nonrepu-diation andmutual authentication In addition the proposedprotocols are lightweight and have improved security sincethey deploy the secure session key generation technique andthe session keys will not be reused

3 The Proposed Mobile Payment Protocols

In this section we apply the fairness model in [28] to mobilepayment protocols to ensure strong fairness Later in thispaper we will show that the proposed protocols satisfy strongfairness Our protocols are composed of two subprotocolsPurchase Credit Request and Making Payment

31 Notations and Assumptions The protocols comprise fourparties a client orC a merchant orM a mobile operator orO(payment gateway) and a trusted third party or TTP Clientsneed to install the proposed software on their mobile devicesThe client who establishes an account with a mobile operatorpays monthly fees

(i) IDA is the identity of A

(ii) DKAB119870119860119861119898119860119861 are the key distribution parametersthat are shared between the parties Readers may findmore details about the key distribution parametersfrom [29] Our protocols used parameters to generatethe secure session key generation technique proposedin [29]

(iii) 119870119860119861 stands for a long-term key

(iv) DKAB stands for a distributed key

(v) 119898119860119861 is a random number It is utilized to indicate thenumber of keys that will be produced

(vi) SKABj where j = 1 m are the session keys sharedbetween party 119860 and party B

(vii) h(M SKABj) is a Message Authentication Code(MAC) of a message119872 and a key SKABj

(viii) h(M) is a hash value of a messageM

(ix) 119872119878119870119860119861119895 is a symmetrically encrypted message of amessage119872 with a key SKABj

(x) CLT is a credit limit up to which the client is allowedto purchase goods or services

(xi) SN is a serial number for a top-up cash card purchasedoffline which infers the credit limit in the clientrsquosaccount

(xii) CLRM is the remaining credit in the clientrsquos account

(xiii) OI = 119879119868119863 119875119903119894119888119890 119874119863 TID is Transaction ID Priceis the price of goods or services and OD is an orderdescription containing details of the goods or servicespurchased

The mobile operator establishes a Transport Layer Secu-rity (TLS) session and shares this KOTTP DKOTTP mOTTPwith TTP Both the mobile operator and TTP create a setof session keys SKOTTPj by using the secure session keygeneration technique proposed in [29] where j = 1 m while implementing the system The proposed protocolsassume that the session keys between parties are the same

32The FairnessModel for Internet Transactions Thammaratet al [28] proposed a fairnessmodel for Internet transactionsThe model supports a mobile payment protocol This modelstill lacks some of the conditions to fully ensure fairnessTherefore we extend the proposed model in [28] to completethe fairness protocols The symbolic notations and modaloperators can be defined as follows

Let 119878 denote a payment system defined as S = 119862119872 119875119866where 119862 is a client who buys goods or services M is amerchant and PG is a payment gateway which acts as thefinancial institution for both 119862 and 119872 In the paymentsystem C acts as the payer and 119872 acts as the payee Inaddition let 119881 be a verifier an external party not involvedin a transaction but trusted by all parties and let TTP denotea trusted third party TTP is not involved in the transactionitself but keeps all transaction data for later verification Rdenotes any party

(i) P authorized X the party 119875 has authorization toperform an action X

(ii) P CanProve X to R the party 119875 is able to prove to theparty 119877 that the statement 119883 is true without revealing anyinformation which is considered to be secret to R

(iii) Payment-order(C M) is the interaction between theclient and the merchant when the client requests to purchasegoods or services from the merchant

(iv) Debit(C PG) is the interaction between the paymentgateway and the client regarding the deduction of the pay-ment token requested by the client from the clientrsquos account

(v) Credit(M PG) is the interaction between the paymentgateway and the merchant in order to transfer the paymenttoken to the merchant account

(vi) Log(C TTP) is the interaction between TTP and theclient enabling TTP to keep all the transactions occurringbetween the client and related parties and send them to theclient

We define a new operator called ldquosatisfiesrdquo which refers tothe situation where a party satisfies the result given at the endof the transaction For example ldquoC satisfies payment-order(CM)rdquo means that the client 119862 has satisfied the results of thetransaction occurring between the client and the merchant

4 Wireless Communications and Mobile Computing

Table 1 Advantages and disadvantages of the types of fairness

Type of Fairness Advantage Disadvantage

No Fairness (i) no cost of TTP(i) very high number of messages(ii) need for reliable network(iii) unable to have dispute resolution

Weak Fairness (i) low number of messages (i) need for reliable network(ii) full TTP

Strong Fairness (i) semi-TTP(ii) no need for reliable network

(i) high number of messages(ii) cost of TTP

The conditions of fairness are as follows Strong fairness(1) TTP is involved (2) There is no information disclosureto TTP Weak fairness (1) TTP is involved (2) There isinformation disclosure to TTP No fairness (1) TTP is notinvolved The details of each condition of fairness can beexplained as follows

(i) TTP is involved TTP keeps all the transactions andprovides the transaction occurring between the parties asevidence when a dispute arises

(ii) TTP is not involved there is no TTP to keep alltransactions and no evidence can be sent to the partiesWhen a dispute arises parties cannot have dispute resolutionIt is not possible to ensure fairness that is not strongly aninvolvement of TTP [21 30]

(iii) Information disclosure to TTP TTP can read alltransactions occurring between the two parties TTPmay sellthe information about parties to the competitors

(iv) No information disclosure to TTP there is no TTPinvolvedTTP cannot read all transactions occurring betweenparties and therefore cannot sell the information aboutparties to the competitors

Table 1 shows the advantages and disadvantages of thetypes of fairness Strong fairness has more advantages thanthe other types for example semi-TTP (semitrusted thirdparty) and it does not need a reliable network In this paperwe will apply Thammaratrsquos fairness model for Internet trans-actions to existing SMS mobile payment protocols for strongfairness Note that a semi-TTP is one that can misbehaveon its own but will not collude with any of the participatingparties

Clientrsquos FairnessThe following requirementsmust be satisfiedfrom the clientrsquos 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 V997888rarr C satisfies payment-order(C M TTP)In each clientrsquos opinion the client will satisfy the trans-

actions only if heshe gets both a payment-order responsefrom the merchant and a debit response from the paymentgateway However the responses must be from the previoustransaction made by the client All requests are sent to thetrusted third party

Merchantrsquos Fairness For a transaction to be satisfactory inthe merchantrsquos opinion the following requirements must besatisfied

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 V997888rarrM satisfies credit (M PG TTP)It can be seen from the above statements that the

merchant will satisfy a transaction if heshe has delivered orcommitted to deliver goods or services to clients as a resultof receiving a payment-order request from the client Thepayment has to be processed by the payment gateway Thepayment gateway must transfer the amount requested by themerchant to the account of themerchant prior to the deliveryof goods or services to the client

Payment Gatewayrsquos Fairness For a transaction to be sat-isfactory in the payment gatewayrsquos opinion the followingrequirements 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 V997888rarr 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 andmerchant Specifically the payment gateway must performactions according to the debit and credit requests made byboth the client and the merchant The payment gatewaytransfers or commits to deduct the amount requested by theclient and transfer the amount requested by the merchant tothe account of the merchant

33 Background Concept on the Secure Session Key GenerationTechnique In this section we will explain the concept of thesecure session key generation technique that is used in a phaseof our proposed protocols The topics that are extensivelydiscussed in symmetric encryptions are the secure sessionkey generation techniques Many researchers have presenteda secure session key generation technique used in their own

Wireless Communications and Mobile Computing 5

Session key3+D D = 1 -

Intermediate key generationRound n

Intermediate key generationRound 1

Preference key generation+C = B(+C-1 $+)

)+1D = B(=IH=(+-C>) )+

1D-1)

)+HD = B(=IH=()+H-1

-C>) )+HD-1)

Figure 1 Session key generator

papers [29 31ndash35] Among all the mentioned approaches[29] proposed a secure session key generation technique thatprevents key compromise attacks Moreover with the securesession key generation technique the parties do not need totransmit a key over the network In our paper we use [29]in introducing our protocols The methodology of [29] isdemonstrated below

Let us assume that party A and party B share 119870119860119861 DKm where 119870119860119861 stands for a long-term key DK stands fora distributed key and 119898 is a random number m is utilizedto indicate the number of keys that will be produced Theconc(M1 M2 M3) shows the concatenation of each of themessages M1 M2 and M3 respectively The secure sessionkey generation technique process is shown in Figure 1

After sharing 119870119860119861 DK m party A and party B create aset of preference keys 119870119894 where i = 1 m as follows 119870119894 =h(119870119894-1 DK) where1198700 =119870119860119861The set of119870119894will be applied as anorigin to invigorate session keys K and DK can be removedfrom the system

Next party A and party B generate sets of intermediatekeys to increase the difficulty for cryptanalysis Moreoverthis makes it more difficult to find the preference key ifthe session key is compromised In each round a new setof intermediate keys is produced Note that the higher thenumber of rounds performed the greater the security ofthe system The intermediate key generation is performedas follows 119868119870119909119895 = ℎ(119888119900119899119888(119868119870119909-1119872119894119889) 119868119870

119909119895-1) where 119909

specifies the number of rounds and j specifies the number of

intermediate keys that are generated j = 1 m 119868119870119909-1119872119894119889stands for the set of 119868119870119909-11198721198941198891 119868119870

119909-11198721198941198892 119868119870

119909-11198721198941198893

1198681198701199091198721198941198891 = 119898119894119889(1198681198701199091 119868119870119909119903119898) and 119903119898 is the remaining

number of intermediate keys in the set of 119868119870119909119895 1198681198701199091198721198941198892 =

119898119894119889(1198681198701199091198721198941198891 119868119870119909119903119898) 1198681198701199091198721198941198893 = 119898119894119889(1198681198701199091 119868119870

1199091198721198941198892)

11986811987011198721198941198891 = 1198701198721198941198891 11986811987011198721198941198891 = 1198701198721198941198892 and 119868119870

11198721198941198891 = 1198701198721198941198893

The generation of11987011987211989411988911198701198721198941198892 and1198701198721198941198893 is the same as thatof 1198681198701199091198721198941198891 1198681198701199091198721198941198892 and 1198681198701199091198721198941198893 respectively 119868119870119909119895-1 = 120593The output of the last round of intermediate key generationis considered as session keys SKj where j = 1 m whichis shown below 1198681198701198991 = 1198781198701 119868119870

1198992 = 1198781198702 119868119870

119899119898 = 119878119870119898

Party A and party B can then use SKj as a credential tosecure transactions as say an encryption key or as an inputto Message Authentication Codes

It can be obviously seen that the session key is createdpurely offline Each party can produce a set of session keysused to secure communication among themselves with norequirements to exchange credentials through the networkas a new session key is not transferred over the network

34 Registration Phase It is assumed that mobile deviceshave the software based on installation of our protocols Oncethe software is loaded the client needs to log on to thepayment system via a secure channel eg TLS (TransportLayer Security) The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119874DKCO 119898119862119874 with the mobile operator The client and themobile operator create a set of session keys SKCOj by usingthe secure session key generation technique proposed in [29]where j = 1 m

(2)The client establishes a TLS session and shares KCTTPDKCTTP mCTTP with TTP The client and TTP create a set ofsession keys SKCTTPj using the secure session key generationtechnique proposed in [29] where j = 1 m

35 Purchase Credit Request Phase In this section before theclient pays for goods or services the client purchases a top-up cash card The client runs the client software from hisherdevice Next he or she fills in the serial number of the top-upcash card and sends the following to the mobile operator

M1 C997888rarrO 119868119863119862 SN1198791 h(SN CLT1198791 SKCOj) h(119868119863119862SN CLT 1198791)119878119870119862119879119879119875119895

M2 O 997888rarr TTP h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 h(CLT1198791 1198792)119878119870119874119879119879119875119895

M3 TTP 997888rarr O h(IDC SN CLT 1198791) h(CLT 11987911198792)119878119870119862119879119879119875119895+1 h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1

M4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SNCLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1

In message M1 the client sends message IDC SN 1198791h(SN CLT 1198791 SKCOj) h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 to themobile operator The message h(SN CLT 1198791 SKCOj) is con-sidered as Message Authentication Code (MAC) which is anauthentication token between the client and the mobile oper-atorMoreover in order to guarantee information correctnessand to defend against erroneous information alteration ordestruction the message h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 willbe transmitted to TTP via the mobile operator Note that 1198791

6 Wireless Communications and Mobile Computing

Table 2 Symbols and abbreviations

Symbol Definition Bits

IDMS1IDMS2IMSI International Mobile Subscriber Identity ofMobile station 80

MACH Message Authentication CodeHash function 160ReqNoSeq Request number 8DK Delegation key 128Order msg Product order 160PriceP Cost of product 64

Withdraw Req Msg Withdraw Resp Msg The customer pays the desired price from hisbank 64

Ack A validation message to the customer 64FS Financial server identification 128Name Name of payer 160NationalID National Identification 104RandomPublicKey The ephemeral public key 128PayeeMobNo Mobile phone number of payee 80Value Digital currency 80IDPRIDPEIDCIDM Identification of Payer PayeeClientMerchant 80Payee Id Identification of Payee 80BI Bank information 128Amt Amount in payerrsquos bank account 64SKBSKPGSKIBSKPGIBSKPGABSKCOSKCTTPSKOTTPSKMTTPSKCMSKMOSKABKPasskeyUAKey

Session Key 128

TSPGTSIBTSBTSPR TT1T2T3T4T5 Timestamp 80NPGNIBNPRNB Nonce 128Payment Notify Payment acknowledgment 128PIPR Payment Information of payer 128TID Transaction ID 128ExpTExpiryKeyExpiry Expiry of primary key 64NSNC Random number 128CertSAG Certificate of Security Access Gateway 40ID ME Mobile phone Number 80CME Certificate of mobile phone 40SN Serial number of the top-up cash card 112CLT Credit limit 40CLRM Remaining credits 40OIOrder Message Order information 160

(YesNo) Purchase credit requestMessage status ofmerchant verifies the goods or services 24

(AcceptReject)Req Msg Payment status 48

denotes the timestamp for the time when the purchase creditis requested and to prevent a replay attack

In message M2 upon receiving this message from theclient the mobile operator sends the message h(IDC SNCLT 1198791)119878119870119862119879119879119875119895 h(CLT 1198791 1198792)119878119870119874119879119879119875119895 to TTP

In message M3 TTP decrypts this message with SKCTTPjand SKOTTPj and keeps the hash value TTP encrypts the hashvalue of h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 with

SKCTTPj+1and encrypts the hash value of h(IDC SN CLT1198791)h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1 with SKOTTPj+1 Then TTP sends allthe messages to the mobile operator Note that 1198792 denotes thetimestamp when the purchase credit is sent to a client and toprevent a replay attack

In message M4 the mobile operator generates messageh(CLT 1198791 1198792 SKCOj+1) which is an authentication tokenbetween the client and the mobile operator Moreover this

Wireless Communications and Mobile Computing 7

Table 3 Cryptographic operation functions

Functions DefinitionDK Encryption with delegation KeySK Encryption with symmetric key encryptionPub Encryption with asymmetric key encryptionf1 Cryptographic function to generate DKf2 Message Authentication Code functionf3 Hash function

Table 4 Message length of our protocols

Message Purchase Credit (Bytes) Making Payment(Bytes)

M1 96 126M2 64 80M3 96 64M4 88 96M5 - 192M6 - 64M7 - 112Total (Bytes) 344 734

message is created in order to guarantee information correct-ness and to defend against erroneous information alterationor destruction Then the mobile operator sends messageh(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 to the client

In the above messages the client supplies the serialnumber of the top-up cash card together with the requestedcredit limit to themobile operatorMobile operators can inferthe credit limit from the serial number given that the serialnumber is from a prepaid cash card Note that serial numberscan also track the credit limit up to which the client is allowedto buy goods or services from the mobile operator Notethat an attacker cannot modify the serial number when theserial number is transmitted in clear text as it is key-hashedin h(SN CLT 1198791 SKCOj) which is a MAC with SKCOj thatis shared between the client and the mobile operator Afterreceiving the demand from the client the mobile operatoradds the credit limit value to the clientrsquos account and sendsa message to the client The mobile operator acknowledgesthe increment of the clientrsquos credit limit During this phasethe client utilizes a top-up cash card in case they do not haveenough credit to make the payment phase

36Making Payment Phase At the beginning of the protocolthe client and the merchant need to establish accounts withtheir mobile operator The mobile operator will deduct acertain amount of value that is purchased by the client whenheshe opens the account There are two major functions onthe clientrsquos side application to operate searching and MakingPayment for goods or services The merchant is the sellerof the goods or services on a mobile portal operated by themobile operator The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119872DKCM119898119862119872with themerchantThe client and themerchant

create a set of session keys SKCMj by using the secure sessionkey generation technique proposed in [29] where j = 1 m

(2) The merchant establishes a TLS session and shares119870119872119874 DKMO119898119872119874 with the mobile operator The merchantand the mobile operator create a set of session keys SKMOjusing the secure session key generation technique proposedin [29] where j = 1 m

(3) The merchant establishes a TLS session and sharesKMTTP DKMTTP mMTTP with TTP They both establish aset of session keys SKMTTPj using the secure session keygeneration technique proposed in [29] where j = 1 m

(4) The client browses lists of goods or services via theapplication on his or her device When the goods or serviceshave been added to the cart the client can make a paymentby the protocol described below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895Otherwise the mobile operator terminates the clientrsquos

requestM5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

In the case of message M1 the client sends messageIDC T IDM OI T h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OIT)119878119870119862119879119879119875119895 to the mobile operator The message IDM OIT h(OI SKCMj)119878119870119862119874119895 is encrypted with SKCOj which isthe session key shared between the client and the mobileoperator for the mobile operation to verify authenticity ofthe client It can be noted that the mobile operator doesnot know the session key SKCMj in order to construct themessage h(OI SKCMj) since it cannot generate thismessage byitself This message h(OI SKCMj) is considered as a MessageAuthentication Code (MAC) which is used to guaranteeinformation correctness and to defend against erroneousinformation alteration or destruction Moreover it enablesthe merchant to verify authenticity of the client The messageh(IDC IDM OI T)119878119870119862119879119879119875119895 will be transmitted to TTP viathe mobile operator It should be noted that 119879 denotes thetimestamp when the payment is requested and to prevent areplay attack

In the case of message M2 upon receiving the messagefrom the client the mobile operator sends message OI h(OISKCMj) h(OI SKCOj+1) T119878119870119872119874119895 to the merchant to verify theauthenticity of the mobile operator The hash value of h(OISKCMj) indicates that the mobile operator does not know thesession key SKCMj that is used to construct the message h(OISKCMj) since it cannot generate this message by itself

8 Wireless Communications and Mobile Computing

Table 5 SMS overhead of our protocols

Session SMS OverheadBytes 7-Bit ASCII (160 Byte) 8-Bit ASCII (140 Byte)

Purchase CreditM1 96 60 6875M4 88 55 6285

Making PaymentM1 126 7875 90M7 112 70 80

Table 6 Comparison of cryptographic operations

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Making PaymentSymmetric Encryption 6 - - 3 2 5 9 3 4 10Asymmetric Encryption - 4 3 4 4 - - 5 - -Message Authentication Code 3 - - 3 - - - 2 2 4Hash Function - - - - 4 2 1 - 2 3Number of Messages 9 6 5 6 6 7 9 6 4 7Number of Parties 4 4 2 5 3 3 4 5 3 4

Table 7 Comparison of energy consumption

AES (121 120583Jbyte) RSA (5465 120583Jbyte) HMAC (116 120583Jbyte) SHA1 (076 120583Jbyte) Total (120583Jbyte)[1] 726 0 348 0 1074[5] 0 2186 0 0 2186[6] 0 16395 0 0 16395[7] 363 2186 348 0 219311[8] 242 2186 0 304 219146[3] 605 0 0 152 757[9] 1089 0 0 076 1165[25] 363 27325 232 0 27385Purchase Credit 484 0 232 152 868Making Payment 121 0 464 228 1902

Table 8 Communication complexity

Protocol Communication cost (bits)

[1] (1)+(2)+(3)+(4)+(5)+(6)+(7)+(8)+(9)=(80+80+160+24)+(80+80+80+80+160+160)+(80+80+80)+(80)+(80+160+64)+(80+24)+(80+24+64+128)+(80)+(24+80)=2192lowastn

[5] (1)+(2)+(3)+(4)+(5)+(6)= (160)+(64+160+80)+(64+48)+(64)+(64)+(64)=768lowastn[6] (1)+(2)+(3)+(4)+(5)=(128)+(160+80+104+160+64+128)+(128)+(128)+(80+80+128+128)=1496lowastn

[7] (1)+(2)+(3)+(4)+(5)+(6)=80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)+(80+64+128+160)+(128+64+80+128+160)+(128+80+128)=3728lowastn

[8] (1)+(2)+(3)+(4)+(5)= (40+80+128+24)+(80)+(40+160)+(128+128+64+160)+(128)=1160lowastn[3] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn[9] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn

[25](1)+(2)+(3)+(4)+(5)+(6)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)

+(128+80+128+128+80+128)+(160+128+128+128+128+80)+(160+128+128+128+128+80)+(128+80+128)=4592lowastn

MakingPayment

(1)+(2)+(3)+(4)+(5)+(6)+(7)=80+80+80+160+80+160+160)+(160+160+160+80)+(24+160+160)+(160+160+160)+(160+160+160+160+160+160+160+160+160)+(160+160+160)

+(48+24+40+160+160+160+160+160)=5016lowastn

Wireless Communications and Mobile Computing 9

Table 9 Computational complexity

Protocol Computational cost[1] f2 f2 SK SK f2 f1 DK f1 SK SK DK=11lowastn[5] Pub Pub Pub Pub=4lowastn[6] Pub f3 Pub SK=4lowastn[7] Pub Pub Pub Pub f2 SK f2 SK f2 SK=10lowastn[8] f3 Pub f3 Pub f2 Pub Pub SK=8lowastn[3] f2 SK SK f1 f2 f1 DK=7lowastn[9] f2 SK SK f1 f2 f1 DK=7lowastn

[25] Pub Pub Pub Pub Pub SK f2 SK f2SK=10lowastn

MakingPayment

f2 SK f3 SK f3 SK f2 SK f3 SK f3 SK SKSK SK f2 SK=17lowastn

In the case of message M3 after receiving the messagefrom the mobile operator the merchant verifies the goodsor services If these are valid a Yes message will be sent tothe mobile operator but if they are invalid a No messagewill be sent to the mobile operator and then the mobileoperator will terminate the clientrsquos request The merchantthen sends the message YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1h(Yes OI)119878119870119872119879119879119875119895 to the mobile operator The messagethat contains YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1 is for themobile operator to verify the authenticity of the merchantIt should be noted that the mobile operator does not knowthe session key SKCMj+1 that is used to construct the messageh(Yes OI SKCMj+1) since it cannot generate this message byitself This message contains h(YesNo OI SKCMj+1) in orderto guarantee information correctness and to defend againsterroneous information alteration or destructionThemessageh(Yes OI)119878119870119872119879119879119875119895 will be transmitted to TTP via the mobileoperator

In the case of message M4 upon receiving this messagefrom the merchant the mobile operator checks the creditbalance and compares it with the requested amount If theclient has enough credit the mobile operator will reply withan Accept message to the client If not the mobile operatorwill reply with a Reject message and then the client has toreturn to the Purchase Credit Request Phase The mobileoperator then sends message h(IDC IDM OI T)119878119870119862119879119879119875119895h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895 toTTP

In the case of message M5 after receiving the mes-sage from the mobile operator TTP decrypts the messageh(IDC IDM OI T)119878119870119862119879119879119875119895 with SKCTTPj h(AcceptRejectOI CLRM)119878119870119874119879119879119875119895 with SKOTTPj and h(Yes OI)119878119870119872119879119879119875119895with SKMTTPj and it keeps the decrypted message toitself Then TTP encrypts the message h(IDC IDM OIT) h(AcceptReject OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 withSKCTTPj+1 h(IDC IDM OI T) h(AcceptReject OI CLRM)h(Yes OI)119878119870119874119879119879119875119895+1 and encrypts themessage with SKOTTPj+1and h(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119872119879119879119875119895+1TTP also encrypts themessage with SKMTTPj+1and sends all the messages to the mobile operator

In the case of message M6 the mobile operator for-wards the message h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1 which is encrypted by TTPwithSKMTTPj+1 to the merchant

In the case of message M7 the mobile operator encryptsmessage one AcceptReject Yes CLRM h(Yes OI SKCMj+1)h(OI SKMOj+1)119878119870119862119874119895+1 with SK119862119874119895+1 while the messageh(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119862119879119879119875119895+1 is encrypted by TTP with SK119862119879119879119875119895+1 to theclient The message that contains AcceptReject Yes CLRMh(YesNo OI SKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 is for the clientto verify the authenticity of themobile operator It can be seenthat the mobile operator cannot deny that the message hasoriginated from himher because only the mobile operatorpossesses both SKMOj +1 and SKCOj+1 This means that themobile operator is the only one that can generate thismessage The hash value of h(YesNo OI SKCMj+1) notes thatthe mobile operator does not know the session key SK119862119872119895+1that is used to construct the message h(Yes OI SKCMj+1) andthe client to verify the authenticity of the merchant since itcannot generate this message by itself

37 Dispute Resolution Phase After the transaction is com-plete if the client is not satisfied with the transaction heshecan request a dispute resolution with the verifier The disputeresolution protocols are composed of two subprotocolsPurchase Credit Request Phase and Making Payment PhaseConsider the protocols below

371 Purchase Credit Request Theclient sends the hash valueh(IDC SN CLT 1198791) h(CLT 1198791 1198792) of the transaction to theverifier Upon receiving the hash value from the client theverifier sends the requested hash value ofTTP After receivingthe hash value fromTTP the verifier compares the hash valuefrom the client with a hash value from TTP If the hash valuesdo not match the verifier rejects the clientrsquos request if notthe verifier sends a notification of dispute resolution to themobile operator to transfer the amount to the clientrsquos accountNote that the verifier stands for the external party and is aparty that is not relevant to the particular transaction

372 Making Payment The client sends the hash valueh(IDC IDM OI T) h (OI CLRM) h(YesNo OI) of thetransaction to the verifier Upon receiving the hash valuefrom the client the verifier sends the requested hash valueof TTP After receiving the hash value from TTP the verifiercompares the hash value from the client with a hash valuefrom TTP If the hash values do not match the verifier rejectsthe clientrsquos request if not the verifier sends a notificationof dispute resolution to the mobile operator to transfer theamount to the clientrsquos account and sends notification to themerchant Note that the verifier stands for the external partyand is a party that is not relevant to the particular transaction

It is obvious that in the Purchase Credit Request Phase(Section 35) and theMaking Payment Phase (Section 36) allmessages received by the TTP are only the hash values of thetransactional data Therefore it is not possible for the TTP to

10 Wireless Communications and Mobile Computing

Table 10 Storage complexity

Protocol Storage cost[1] (1)+(2)+(3)+(4)=(80+80+160+24)+(80+160+64)+(80+24=104)+(24+80)=856lowastn[5] (1)+(2)+(3)+(4)=(160)+(64+160+80)+(64+48)+(64)=640lowastn[6] (1)+(2)+(3)= (128)+(160+80+104+160+64+128)+(80+80+128+128)=1240lowastn[7] (1)+(2)+(3)=(80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)=2400lowastn[8] (1)+(2)+(3)=(40+80+128+24)+(128+128+64+160)+(128)=880lowastn[3] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn[9] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn

[25] (1)+(2)+(3)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)+(128+80+128+128+80+128)=2752lowastn

MakingPayment (1)+(2)=(80+80+80+160+80+160+160)+(48+24+40+160+160+160+160+160)=1712lowastn

Table 11 Comparison of mobile payment protocols

Protocol Type of Fairness Uses TTP TTP Type[1] No Fairness No Without TTP[5] No Fairness No Without TTP[6] No Fairness No Without TTP[7] No Fairness No Without TTP[8] No Fairness No Without TTP[3] No Fairness No Without TTP[9] Weak Fairness Yes Online[25] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

accessmeaningful information of the transactionThismakesour protocols have strong fairness

4 Discussion

41 Security Analysis (1) Brute force attacks for the comple-tion of a transaction of our protocols the session keys changeevery time and are not reused therefore it is difficult for theattacker to find the correct session key that is shared betweenparties In addition according to [29] a brute force attackis difficult to complete by applying an offline key generationtechnique

(2) Replay attack prevention the attacker intersects themessage and resends an old message Our protocols are usedonly once with a fresh timestamp so a replay attack can beprevented and is difficult to accomplish For further detailsabout this technique the reader is referred to [29]

(3) Message integrity the integrity of the message is themost important security property that any party can ensureso that the message guarantees information correctness andis defended against erroneous information alteration ordestruction during the transmission With our protocolseach message comprises a Message Authentication Code(MAC) value that ensures the recipient of the message andthe same recent key can be used to generate a newMACThereceived MAC is compared with the calculated MAC

(4) Mutual authentication this is used to check who theoriginator and the receiver of a message are Our protocolsdeployMACs and symmetric cryptographic operations Onlythe originator and the receiver who share the same key will beable to encrypt and decrypt their messages As a result of ourprotocols eachmessage can be used to identify the originatorand the receiver so that the client the merchant and themobile operator ensure mutual authentication Consider themessage below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client and the mobile operatorshare the session key SKCOj but the mobile operator cannotgenerate thismessage by himself or herself because themobileoperator cannot generate h(OI SKCMj) as the session keySKCMj is shared only between the merchant and the clientOnly the session keys SKCMj and SKCOj are known by theclient therefore guaranteeing that the client generated thismessage

(5)Man-in-the-middle attacks an attacker cannot imper-sonate a party by intercepting message passes in theseprotocolsWith the use of limited-use session keys and propercryptographic operations no confidential information isrevealed and the reuse of authentication information islimited In addition the session keys used in our protocolsare changed constantly using strong encryption techniques

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 3: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Wireless Communications and Mobile Computing 3

validated using formal methods utilizing a model-checkingtool called Scyther

Unfortunately most of the mobile payment systemsthat have thus far been proposed still lack fairness Forexample some systems allow disclosure of information tothe trusted third party and some do not even involvea trusted third party In addition many researchers haveproposedmobile payment protocols withweaknesses in someareas such as confidentiality integrity nonrepudiation andmutual authentication Mutual authentication can preventboth replay attacks and man-in-the-middle attacks whichis critical for information security This paper introducesmobile payment protocols that enhance fairness and providesecurity properties such as confidentiality integrity nonrepu-diation andmutual authentication In addition the proposedprotocols are lightweight and have improved security sincethey deploy the secure session key generation technique andthe session keys will not be reused

3 The Proposed Mobile Payment Protocols

In this section we apply the fairness model in [28] to mobilepayment protocols to ensure strong fairness Later in thispaper we will show that the proposed protocols satisfy strongfairness Our protocols are composed of two subprotocolsPurchase Credit Request and Making Payment

31 Notations and Assumptions The protocols comprise fourparties a client orC a merchant orM a mobile operator orO(payment gateway) and a trusted third party or TTP Clientsneed to install the proposed software on their mobile devicesThe client who establishes an account with a mobile operatorpays monthly fees

(i) IDA is the identity of A

(ii) DKAB119870119860119861119898119860119861 are the key distribution parametersthat are shared between the parties Readers may findmore details about the key distribution parametersfrom [29] Our protocols used parameters to generatethe secure session key generation technique proposedin [29]

(iii) 119870119860119861 stands for a long-term key

(iv) DKAB stands for a distributed key

(v) 119898119860119861 is a random number It is utilized to indicate thenumber of keys that will be produced

(vi) SKABj where j = 1 m are the session keys sharedbetween party 119860 and party B

(vii) h(M SKABj) is a Message Authentication Code(MAC) of a message119872 and a key SKABj

(viii) h(M) is a hash value of a messageM

(ix) 119872119878119870119860119861119895 is a symmetrically encrypted message of amessage119872 with a key SKABj

(x) CLT is a credit limit up to which the client is allowedto purchase goods or services

(xi) SN is a serial number for a top-up cash card purchasedoffline which infers the credit limit in the clientrsquosaccount

(xii) CLRM is the remaining credit in the clientrsquos account

(xiii) OI = 119879119868119863 119875119903119894119888119890 119874119863 TID is Transaction ID Priceis the price of goods or services and OD is an orderdescription containing details of the goods or servicespurchased

The mobile operator establishes a Transport Layer Secu-rity (TLS) session and shares this KOTTP DKOTTP mOTTPwith TTP Both the mobile operator and TTP create a setof session keys SKOTTPj by using the secure session keygeneration technique proposed in [29] where j = 1 m while implementing the system The proposed protocolsassume that the session keys between parties are the same

32The FairnessModel for Internet Transactions Thammaratet al [28] proposed a fairnessmodel for Internet transactionsThe model supports a mobile payment protocol This modelstill lacks some of the conditions to fully ensure fairnessTherefore we extend the proposed model in [28] to completethe fairness protocols The symbolic notations and modaloperators can be defined as follows

Let 119878 denote a payment system defined as S = 119862119872 119875119866where 119862 is a client who buys goods or services M is amerchant and PG is a payment gateway which acts as thefinancial institution for both 119862 and 119872 In the paymentsystem C acts as the payer and 119872 acts as the payee Inaddition let 119881 be a verifier an external party not involvedin a transaction but trusted by all parties and let TTP denotea trusted third party TTP is not involved in the transactionitself but keeps all transaction data for later verification Rdenotes any party

(i) P authorized X the party 119875 has authorization toperform an action X

(ii) P CanProve X to R the party 119875 is able to prove to theparty 119877 that the statement 119883 is true without revealing anyinformation which is considered to be secret to R

(iii) Payment-order(C M) is the interaction between theclient and the merchant when the client requests to purchasegoods or services from the merchant

(iv) Debit(C PG) is the interaction between the paymentgateway and the client regarding the deduction of the pay-ment token requested by the client from the clientrsquos account

(v) Credit(M PG) is the interaction between the paymentgateway and the merchant in order to transfer the paymenttoken to the merchant account

(vi) Log(C TTP) is the interaction between TTP and theclient enabling TTP to keep all the transactions occurringbetween the client and related parties and send them to theclient

We define a new operator called ldquosatisfiesrdquo which refers tothe situation where a party satisfies the result given at the endof the transaction For example ldquoC satisfies payment-order(CM)rdquo means that the client 119862 has satisfied the results of thetransaction occurring between the client and the merchant

4 Wireless Communications and Mobile Computing

Table 1 Advantages and disadvantages of the types of fairness

Type of Fairness Advantage Disadvantage

No Fairness (i) no cost of TTP(i) very high number of messages(ii) need for reliable network(iii) unable to have dispute resolution

Weak Fairness (i) low number of messages (i) need for reliable network(ii) full TTP

Strong Fairness (i) semi-TTP(ii) no need for reliable network

(i) high number of messages(ii) cost of TTP

The conditions of fairness are as follows Strong fairness(1) TTP is involved (2) There is no information disclosureto TTP Weak fairness (1) TTP is involved (2) There isinformation disclosure to TTP No fairness (1) TTP is notinvolved The details of each condition of fairness can beexplained as follows

(i) TTP is involved TTP keeps all the transactions andprovides the transaction occurring between the parties asevidence when a dispute arises

(ii) TTP is not involved there is no TTP to keep alltransactions and no evidence can be sent to the partiesWhen a dispute arises parties cannot have dispute resolutionIt is not possible to ensure fairness that is not strongly aninvolvement of TTP [21 30]

(iii) Information disclosure to TTP TTP can read alltransactions occurring between the two parties TTPmay sellthe information about parties to the competitors

(iv) No information disclosure to TTP there is no TTPinvolvedTTP cannot read all transactions occurring betweenparties and therefore cannot sell the information aboutparties to the competitors

Table 1 shows the advantages and disadvantages of thetypes of fairness Strong fairness has more advantages thanthe other types for example semi-TTP (semitrusted thirdparty) and it does not need a reliable network In this paperwe will apply Thammaratrsquos fairness model for Internet trans-actions to existing SMS mobile payment protocols for strongfairness Note that a semi-TTP is one that can misbehaveon its own but will not collude with any of the participatingparties

Clientrsquos FairnessThe following requirementsmust be satisfiedfrom the clientrsquos 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 V997888rarr C satisfies payment-order(C M TTP)In each clientrsquos opinion the client will satisfy the trans-

actions only if heshe gets both a payment-order responsefrom the merchant and a debit response from the paymentgateway However the responses must be from the previoustransaction made by the client All requests are sent to thetrusted third party

Merchantrsquos Fairness For a transaction to be satisfactory inthe merchantrsquos opinion the following requirements must besatisfied

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 V997888rarrM satisfies credit (M PG TTP)It can be seen from the above statements that the

merchant will satisfy a transaction if heshe has delivered orcommitted to deliver goods or services to clients as a resultof receiving a payment-order request from the client Thepayment has to be processed by the payment gateway Thepayment gateway must transfer the amount requested by themerchant to the account of themerchant prior to the deliveryof goods or services to the client

Payment Gatewayrsquos Fairness For a transaction to be sat-isfactory in the payment gatewayrsquos opinion the followingrequirements 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 V997888rarr 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 andmerchant Specifically the payment gateway must performactions according to the debit and credit requests made byboth the client and the merchant The payment gatewaytransfers or commits to deduct the amount requested by theclient and transfer the amount requested by the merchant tothe account of the merchant

33 Background Concept on the Secure Session Key GenerationTechnique In this section we will explain the concept of thesecure session key generation technique that is used in a phaseof our proposed protocols The topics that are extensivelydiscussed in symmetric encryptions are the secure sessionkey generation techniques Many researchers have presenteda secure session key generation technique used in their own

Wireless Communications and Mobile Computing 5

Session key3+D D = 1 -

Intermediate key generationRound n

Intermediate key generationRound 1

Preference key generation+C = B(+C-1 $+)

)+1D = B(=IH=(+-C>) )+

1D-1)

)+HD = B(=IH=()+H-1

-C>) )+HD-1)

Figure 1 Session key generator

papers [29 31ndash35] Among all the mentioned approaches[29] proposed a secure session key generation technique thatprevents key compromise attacks Moreover with the securesession key generation technique the parties do not need totransmit a key over the network In our paper we use [29]in introducing our protocols The methodology of [29] isdemonstrated below

Let us assume that party A and party B share 119870119860119861 DKm where 119870119860119861 stands for a long-term key DK stands fora distributed key and 119898 is a random number m is utilizedto indicate the number of keys that will be produced Theconc(M1 M2 M3) shows the concatenation of each of themessages M1 M2 and M3 respectively The secure sessionkey generation technique process is shown in Figure 1

After sharing 119870119860119861 DK m party A and party B create aset of preference keys 119870119894 where i = 1 m as follows 119870119894 =h(119870119894-1 DK) where1198700 =119870119860119861The set of119870119894will be applied as anorigin to invigorate session keys K and DK can be removedfrom the system

Next party A and party B generate sets of intermediatekeys to increase the difficulty for cryptanalysis Moreoverthis makes it more difficult to find the preference key ifthe session key is compromised In each round a new setof intermediate keys is produced Note that the higher thenumber of rounds performed the greater the security ofthe system The intermediate key generation is performedas follows 119868119870119909119895 = ℎ(119888119900119899119888(119868119870119909-1119872119894119889) 119868119870

119909119895-1) where 119909

specifies the number of rounds and j specifies the number of

intermediate keys that are generated j = 1 m 119868119870119909-1119872119894119889stands for the set of 119868119870119909-11198721198941198891 119868119870

119909-11198721198941198892 119868119870

119909-11198721198941198893

1198681198701199091198721198941198891 = 119898119894119889(1198681198701199091 119868119870119909119903119898) and 119903119898 is the remaining

number of intermediate keys in the set of 119868119870119909119895 1198681198701199091198721198941198892 =

119898119894119889(1198681198701199091198721198941198891 119868119870119909119903119898) 1198681198701199091198721198941198893 = 119898119894119889(1198681198701199091 119868119870

1199091198721198941198892)

11986811987011198721198941198891 = 1198701198721198941198891 11986811987011198721198941198891 = 1198701198721198941198892 and 119868119870

11198721198941198891 = 1198701198721198941198893

The generation of11987011987211989411988911198701198721198941198892 and1198701198721198941198893 is the same as thatof 1198681198701199091198721198941198891 1198681198701199091198721198941198892 and 1198681198701199091198721198941198893 respectively 119868119870119909119895-1 = 120593The output of the last round of intermediate key generationis considered as session keys SKj where j = 1 m whichis shown below 1198681198701198991 = 1198781198701 119868119870

1198992 = 1198781198702 119868119870

119899119898 = 119878119870119898

Party A and party B can then use SKj as a credential tosecure transactions as say an encryption key or as an inputto Message Authentication Codes

It can be obviously seen that the session key is createdpurely offline Each party can produce a set of session keysused to secure communication among themselves with norequirements to exchange credentials through the networkas a new session key is not transferred over the network

34 Registration Phase It is assumed that mobile deviceshave the software based on installation of our protocols Oncethe software is loaded the client needs to log on to thepayment system via a secure channel eg TLS (TransportLayer Security) The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119874DKCO 119898119862119874 with the mobile operator The client and themobile operator create a set of session keys SKCOj by usingthe secure session key generation technique proposed in [29]where j = 1 m

(2)The client establishes a TLS session and shares KCTTPDKCTTP mCTTP with TTP The client and TTP create a set ofsession keys SKCTTPj using the secure session key generationtechnique proposed in [29] where j = 1 m

35 Purchase Credit Request Phase In this section before theclient pays for goods or services the client purchases a top-up cash card The client runs the client software from hisherdevice Next he or she fills in the serial number of the top-upcash card and sends the following to the mobile operator

M1 C997888rarrO 119868119863119862 SN1198791 h(SN CLT1198791 SKCOj) h(119868119863119862SN CLT 1198791)119878119870119862119879119879119875119895

M2 O 997888rarr TTP h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 h(CLT1198791 1198792)119878119870119874119879119879119875119895

M3 TTP 997888rarr O h(IDC SN CLT 1198791) h(CLT 11987911198792)119878119870119862119879119879119875119895+1 h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1

M4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SNCLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1

In message M1 the client sends message IDC SN 1198791h(SN CLT 1198791 SKCOj) h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 to themobile operator The message h(SN CLT 1198791 SKCOj) is con-sidered as Message Authentication Code (MAC) which is anauthentication token between the client and the mobile oper-atorMoreover in order to guarantee information correctnessand to defend against erroneous information alteration ordestruction the message h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 willbe transmitted to TTP via the mobile operator Note that 1198791

6 Wireless Communications and Mobile Computing

Table 2 Symbols and abbreviations

Symbol Definition Bits

IDMS1IDMS2IMSI International Mobile Subscriber Identity ofMobile station 80

MACH Message Authentication CodeHash function 160ReqNoSeq Request number 8DK Delegation key 128Order msg Product order 160PriceP Cost of product 64

Withdraw Req Msg Withdraw Resp Msg The customer pays the desired price from hisbank 64

Ack A validation message to the customer 64FS Financial server identification 128Name Name of payer 160NationalID National Identification 104RandomPublicKey The ephemeral public key 128PayeeMobNo Mobile phone number of payee 80Value Digital currency 80IDPRIDPEIDCIDM Identification of Payer PayeeClientMerchant 80Payee Id Identification of Payee 80BI Bank information 128Amt Amount in payerrsquos bank account 64SKBSKPGSKIBSKPGIBSKPGABSKCOSKCTTPSKOTTPSKMTTPSKCMSKMOSKABKPasskeyUAKey

Session Key 128

TSPGTSIBTSBTSPR TT1T2T3T4T5 Timestamp 80NPGNIBNPRNB Nonce 128Payment Notify Payment acknowledgment 128PIPR Payment Information of payer 128TID Transaction ID 128ExpTExpiryKeyExpiry Expiry of primary key 64NSNC Random number 128CertSAG Certificate of Security Access Gateway 40ID ME Mobile phone Number 80CME Certificate of mobile phone 40SN Serial number of the top-up cash card 112CLT Credit limit 40CLRM Remaining credits 40OIOrder Message Order information 160

(YesNo) Purchase credit requestMessage status ofmerchant verifies the goods or services 24

(AcceptReject)Req Msg Payment status 48

denotes the timestamp for the time when the purchase creditis requested and to prevent a replay attack

In message M2 upon receiving this message from theclient the mobile operator sends the message h(IDC SNCLT 1198791)119878119870119862119879119879119875119895 h(CLT 1198791 1198792)119878119870119874119879119879119875119895 to TTP

In message M3 TTP decrypts this message with SKCTTPjand SKOTTPj and keeps the hash value TTP encrypts the hashvalue of h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 with

SKCTTPj+1and encrypts the hash value of h(IDC SN CLT1198791)h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1 with SKOTTPj+1 Then TTP sends allthe messages to the mobile operator Note that 1198792 denotes thetimestamp when the purchase credit is sent to a client and toprevent a replay attack

In message M4 the mobile operator generates messageh(CLT 1198791 1198792 SKCOj+1) which is an authentication tokenbetween the client and the mobile operator Moreover this

Wireless Communications and Mobile Computing 7

Table 3 Cryptographic operation functions

Functions DefinitionDK Encryption with delegation KeySK Encryption with symmetric key encryptionPub Encryption with asymmetric key encryptionf1 Cryptographic function to generate DKf2 Message Authentication Code functionf3 Hash function

Table 4 Message length of our protocols

Message Purchase Credit (Bytes) Making Payment(Bytes)

M1 96 126M2 64 80M3 96 64M4 88 96M5 - 192M6 - 64M7 - 112Total (Bytes) 344 734

message is created in order to guarantee information correct-ness and to defend against erroneous information alterationor destruction Then the mobile operator sends messageh(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 to the client

In the above messages the client supplies the serialnumber of the top-up cash card together with the requestedcredit limit to themobile operatorMobile operators can inferthe credit limit from the serial number given that the serialnumber is from a prepaid cash card Note that serial numberscan also track the credit limit up to which the client is allowedto buy goods or services from the mobile operator Notethat an attacker cannot modify the serial number when theserial number is transmitted in clear text as it is key-hashedin h(SN CLT 1198791 SKCOj) which is a MAC with SKCOj thatis shared between the client and the mobile operator Afterreceiving the demand from the client the mobile operatoradds the credit limit value to the clientrsquos account and sendsa message to the client The mobile operator acknowledgesthe increment of the clientrsquos credit limit During this phasethe client utilizes a top-up cash card in case they do not haveenough credit to make the payment phase

36Making Payment Phase At the beginning of the protocolthe client and the merchant need to establish accounts withtheir mobile operator The mobile operator will deduct acertain amount of value that is purchased by the client whenheshe opens the account There are two major functions onthe clientrsquos side application to operate searching and MakingPayment for goods or services The merchant is the sellerof the goods or services on a mobile portal operated by themobile operator The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119872DKCM119898119862119872with themerchantThe client and themerchant

create a set of session keys SKCMj by using the secure sessionkey generation technique proposed in [29] where j = 1 m

(2) The merchant establishes a TLS session and shares119870119872119874 DKMO119898119872119874 with the mobile operator The merchantand the mobile operator create a set of session keys SKMOjusing the secure session key generation technique proposedin [29] where j = 1 m

(3) The merchant establishes a TLS session and sharesKMTTP DKMTTP mMTTP with TTP They both establish aset of session keys SKMTTPj using the secure session keygeneration technique proposed in [29] where j = 1 m

(4) The client browses lists of goods or services via theapplication on his or her device When the goods or serviceshave been added to the cart the client can make a paymentby the protocol described below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895Otherwise the mobile operator terminates the clientrsquos

requestM5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

In the case of message M1 the client sends messageIDC T IDM OI T h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OIT)119878119870119862119879119879119875119895 to the mobile operator The message IDM OIT h(OI SKCMj)119878119870119862119874119895 is encrypted with SKCOj which isthe session key shared between the client and the mobileoperator for the mobile operation to verify authenticity ofthe client It can be noted that the mobile operator doesnot know the session key SKCMj in order to construct themessage h(OI SKCMj) since it cannot generate thismessage byitself This message h(OI SKCMj) is considered as a MessageAuthentication Code (MAC) which is used to guaranteeinformation correctness and to defend against erroneousinformation alteration or destruction Moreover it enablesthe merchant to verify authenticity of the client The messageh(IDC IDM OI T)119878119870119862119879119879119875119895 will be transmitted to TTP viathe mobile operator It should be noted that 119879 denotes thetimestamp when the payment is requested and to prevent areplay attack

In the case of message M2 upon receiving the messagefrom the client the mobile operator sends message OI h(OISKCMj) h(OI SKCOj+1) T119878119870119872119874119895 to the merchant to verify theauthenticity of the mobile operator The hash value of h(OISKCMj) indicates that the mobile operator does not know thesession key SKCMj that is used to construct the message h(OISKCMj) since it cannot generate this message by itself

8 Wireless Communications and Mobile Computing

Table 5 SMS overhead of our protocols

Session SMS OverheadBytes 7-Bit ASCII (160 Byte) 8-Bit ASCII (140 Byte)

Purchase CreditM1 96 60 6875M4 88 55 6285

Making PaymentM1 126 7875 90M7 112 70 80

Table 6 Comparison of cryptographic operations

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Making PaymentSymmetric Encryption 6 - - 3 2 5 9 3 4 10Asymmetric Encryption - 4 3 4 4 - - 5 - -Message Authentication Code 3 - - 3 - - - 2 2 4Hash Function - - - - 4 2 1 - 2 3Number of Messages 9 6 5 6 6 7 9 6 4 7Number of Parties 4 4 2 5 3 3 4 5 3 4

Table 7 Comparison of energy consumption

AES (121 120583Jbyte) RSA (5465 120583Jbyte) HMAC (116 120583Jbyte) SHA1 (076 120583Jbyte) Total (120583Jbyte)[1] 726 0 348 0 1074[5] 0 2186 0 0 2186[6] 0 16395 0 0 16395[7] 363 2186 348 0 219311[8] 242 2186 0 304 219146[3] 605 0 0 152 757[9] 1089 0 0 076 1165[25] 363 27325 232 0 27385Purchase Credit 484 0 232 152 868Making Payment 121 0 464 228 1902

Table 8 Communication complexity

Protocol Communication cost (bits)

[1] (1)+(2)+(3)+(4)+(5)+(6)+(7)+(8)+(9)=(80+80+160+24)+(80+80+80+80+160+160)+(80+80+80)+(80)+(80+160+64)+(80+24)+(80+24+64+128)+(80)+(24+80)=2192lowastn

[5] (1)+(2)+(3)+(4)+(5)+(6)= (160)+(64+160+80)+(64+48)+(64)+(64)+(64)=768lowastn[6] (1)+(2)+(3)+(4)+(5)=(128)+(160+80+104+160+64+128)+(128)+(128)+(80+80+128+128)=1496lowastn

[7] (1)+(2)+(3)+(4)+(5)+(6)=80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)+(80+64+128+160)+(128+64+80+128+160)+(128+80+128)=3728lowastn

[8] (1)+(2)+(3)+(4)+(5)= (40+80+128+24)+(80)+(40+160)+(128+128+64+160)+(128)=1160lowastn[3] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn[9] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn

[25](1)+(2)+(3)+(4)+(5)+(6)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)

+(128+80+128+128+80+128)+(160+128+128+128+128+80)+(160+128+128+128+128+80)+(128+80+128)=4592lowastn

MakingPayment

(1)+(2)+(3)+(4)+(5)+(6)+(7)=80+80+80+160+80+160+160)+(160+160+160+80)+(24+160+160)+(160+160+160)+(160+160+160+160+160+160+160+160+160)+(160+160+160)

+(48+24+40+160+160+160+160+160)=5016lowastn

Wireless Communications and Mobile Computing 9

Table 9 Computational complexity

Protocol Computational cost[1] f2 f2 SK SK f2 f1 DK f1 SK SK DK=11lowastn[5] Pub Pub Pub Pub=4lowastn[6] Pub f3 Pub SK=4lowastn[7] Pub Pub Pub Pub f2 SK f2 SK f2 SK=10lowastn[8] f3 Pub f3 Pub f2 Pub Pub SK=8lowastn[3] f2 SK SK f1 f2 f1 DK=7lowastn[9] f2 SK SK f1 f2 f1 DK=7lowastn

[25] Pub Pub Pub Pub Pub SK f2 SK f2SK=10lowastn

MakingPayment

f2 SK f3 SK f3 SK f2 SK f3 SK f3 SK SKSK SK f2 SK=17lowastn

In the case of message M3 after receiving the messagefrom the mobile operator the merchant verifies the goodsor services If these are valid a Yes message will be sent tothe mobile operator but if they are invalid a No messagewill be sent to the mobile operator and then the mobileoperator will terminate the clientrsquos request The merchantthen sends the message YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1h(Yes OI)119878119870119872119879119879119875119895 to the mobile operator The messagethat contains YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1 is for themobile operator to verify the authenticity of the merchantIt should be noted that the mobile operator does not knowthe session key SKCMj+1 that is used to construct the messageh(Yes OI SKCMj+1) since it cannot generate this message byitself This message contains h(YesNo OI SKCMj+1) in orderto guarantee information correctness and to defend againsterroneous information alteration or destructionThemessageh(Yes OI)119878119870119872119879119879119875119895 will be transmitted to TTP via the mobileoperator

In the case of message M4 upon receiving this messagefrom the merchant the mobile operator checks the creditbalance and compares it with the requested amount If theclient has enough credit the mobile operator will reply withan Accept message to the client If not the mobile operatorwill reply with a Reject message and then the client has toreturn to the Purchase Credit Request Phase The mobileoperator then sends message h(IDC IDM OI T)119878119870119862119879119879119875119895h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895 toTTP

In the case of message M5 after receiving the mes-sage from the mobile operator TTP decrypts the messageh(IDC IDM OI T)119878119870119862119879119879119875119895 with SKCTTPj h(AcceptRejectOI CLRM)119878119870119874119879119879119875119895 with SKOTTPj and h(Yes OI)119878119870119872119879119879119875119895with SKMTTPj and it keeps the decrypted message toitself Then TTP encrypts the message h(IDC IDM OIT) h(AcceptReject OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 withSKCTTPj+1 h(IDC IDM OI T) h(AcceptReject OI CLRM)h(Yes OI)119878119870119874119879119879119875119895+1 and encrypts themessage with SKOTTPj+1and h(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119872119879119879119875119895+1TTP also encrypts themessage with SKMTTPj+1and sends all the messages to the mobile operator

In the case of message M6 the mobile operator for-wards the message h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1 which is encrypted by TTPwithSKMTTPj+1 to the merchant

In the case of message M7 the mobile operator encryptsmessage one AcceptReject Yes CLRM h(Yes OI SKCMj+1)h(OI SKMOj+1)119878119870119862119874119895+1 with SK119862119874119895+1 while the messageh(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119862119879119879119875119895+1 is encrypted by TTP with SK119862119879119879119875119895+1 to theclient The message that contains AcceptReject Yes CLRMh(YesNo OI SKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 is for the clientto verify the authenticity of themobile operator It can be seenthat the mobile operator cannot deny that the message hasoriginated from himher because only the mobile operatorpossesses both SKMOj +1 and SKCOj+1 This means that themobile operator is the only one that can generate thismessage The hash value of h(YesNo OI SKCMj+1) notes thatthe mobile operator does not know the session key SK119862119872119895+1that is used to construct the message h(Yes OI SKCMj+1) andthe client to verify the authenticity of the merchant since itcannot generate this message by itself

37 Dispute Resolution Phase After the transaction is com-plete if the client is not satisfied with the transaction heshecan request a dispute resolution with the verifier The disputeresolution protocols are composed of two subprotocolsPurchase Credit Request Phase and Making Payment PhaseConsider the protocols below

371 Purchase Credit Request Theclient sends the hash valueh(IDC SN CLT 1198791) h(CLT 1198791 1198792) of the transaction to theverifier Upon receiving the hash value from the client theverifier sends the requested hash value ofTTP After receivingthe hash value fromTTP the verifier compares the hash valuefrom the client with a hash value from TTP If the hash valuesdo not match the verifier rejects the clientrsquos request if notthe verifier sends a notification of dispute resolution to themobile operator to transfer the amount to the clientrsquos accountNote that the verifier stands for the external party and is aparty that is not relevant to the particular transaction

372 Making Payment The client sends the hash valueh(IDC IDM OI T) h (OI CLRM) h(YesNo OI) of thetransaction to the verifier Upon receiving the hash valuefrom the client the verifier sends the requested hash valueof TTP After receiving the hash value from TTP the verifiercompares the hash value from the client with a hash valuefrom TTP If the hash values do not match the verifier rejectsthe clientrsquos request if not the verifier sends a notificationof dispute resolution to the mobile operator to transfer theamount to the clientrsquos account and sends notification to themerchant Note that the verifier stands for the external partyand is a party that is not relevant to the particular transaction

It is obvious that in the Purchase Credit Request Phase(Section 35) and theMaking Payment Phase (Section 36) allmessages received by the TTP are only the hash values of thetransactional data Therefore it is not possible for the TTP to

10 Wireless Communications and Mobile Computing

Table 10 Storage complexity

Protocol Storage cost[1] (1)+(2)+(3)+(4)=(80+80+160+24)+(80+160+64)+(80+24=104)+(24+80)=856lowastn[5] (1)+(2)+(3)+(4)=(160)+(64+160+80)+(64+48)+(64)=640lowastn[6] (1)+(2)+(3)= (128)+(160+80+104+160+64+128)+(80+80+128+128)=1240lowastn[7] (1)+(2)+(3)=(80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)=2400lowastn[8] (1)+(2)+(3)=(40+80+128+24)+(128+128+64+160)+(128)=880lowastn[3] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn[9] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn

[25] (1)+(2)+(3)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)+(128+80+128+128+80+128)=2752lowastn

MakingPayment (1)+(2)=(80+80+80+160+80+160+160)+(48+24+40+160+160+160+160+160)=1712lowastn

Table 11 Comparison of mobile payment protocols

Protocol Type of Fairness Uses TTP TTP Type[1] No Fairness No Without TTP[5] No Fairness No Without TTP[6] No Fairness No Without TTP[7] No Fairness No Without TTP[8] No Fairness No Without TTP[3] No Fairness No Without TTP[9] Weak Fairness Yes Online[25] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

accessmeaningful information of the transactionThismakesour protocols have strong fairness

4 Discussion

41 Security Analysis (1) Brute force attacks for the comple-tion of a transaction of our protocols the session keys changeevery time and are not reused therefore it is difficult for theattacker to find the correct session key that is shared betweenparties In addition according to [29] a brute force attackis difficult to complete by applying an offline key generationtechnique

(2) Replay attack prevention the attacker intersects themessage and resends an old message Our protocols are usedonly once with a fresh timestamp so a replay attack can beprevented and is difficult to accomplish For further detailsabout this technique the reader is referred to [29]

(3) Message integrity the integrity of the message is themost important security property that any party can ensureso that the message guarantees information correctness andis defended against erroneous information alteration ordestruction during the transmission With our protocolseach message comprises a Message Authentication Code(MAC) value that ensures the recipient of the message andthe same recent key can be used to generate a newMACThereceived MAC is compared with the calculated MAC

(4) Mutual authentication this is used to check who theoriginator and the receiver of a message are Our protocolsdeployMACs and symmetric cryptographic operations Onlythe originator and the receiver who share the same key will beable to encrypt and decrypt their messages As a result of ourprotocols eachmessage can be used to identify the originatorand the receiver so that the client the merchant and themobile operator ensure mutual authentication Consider themessage below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client and the mobile operatorshare the session key SKCOj but the mobile operator cannotgenerate thismessage by himself or herself because themobileoperator cannot generate h(OI SKCMj) as the session keySKCMj is shared only between the merchant and the clientOnly the session keys SKCMj and SKCOj are known by theclient therefore guaranteeing that the client generated thismessage

(5)Man-in-the-middle attacks an attacker cannot imper-sonate a party by intercepting message passes in theseprotocolsWith the use of limited-use session keys and propercryptographic operations no confidential information isrevealed and the reuse of authentication information islimited In addition the session keys used in our protocolsare changed constantly using strong encryption techniques

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 4: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

4 Wireless Communications and Mobile Computing

Table 1 Advantages and disadvantages of the types of fairness

Type of Fairness Advantage Disadvantage

No Fairness (i) no cost of TTP(i) very high number of messages(ii) need for reliable network(iii) unable to have dispute resolution

Weak Fairness (i) low number of messages (i) need for reliable network(ii) full TTP

Strong Fairness (i) semi-TTP(ii) no need for reliable network

(i) high number of messages(ii) cost of TTP

The conditions of fairness are as follows Strong fairness(1) TTP is involved (2) There is no information disclosureto TTP Weak fairness (1) TTP is involved (2) There isinformation disclosure to TTP No fairness (1) TTP is notinvolved The details of each condition of fairness can beexplained as follows

(i) TTP is involved TTP keeps all the transactions andprovides the transaction occurring between the parties asevidence when a dispute arises

(ii) TTP is not involved there is no TTP to keep alltransactions and no evidence can be sent to the partiesWhen a dispute arises parties cannot have dispute resolutionIt is not possible to ensure fairness that is not strongly aninvolvement of TTP [21 30]

(iii) Information disclosure to TTP TTP can read alltransactions occurring between the two parties TTPmay sellthe information about parties to the competitors

(iv) No information disclosure to TTP there is no TTPinvolvedTTP cannot read all transactions occurring betweenparties and therefore cannot sell the information aboutparties to the competitors

Table 1 shows the advantages and disadvantages of thetypes of fairness Strong fairness has more advantages thanthe other types for example semi-TTP (semitrusted thirdparty) and it does not need a reliable network In this paperwe will apply Thammaratrsquos fairness model for Internet trans-actions to existing SMS mobile payment protocols for strongfairness Note that a semi-TTP is one that can misbehaveon its own but will not collude with any of the participatingparties

Clientrsquos FairnessThe following requirementsmust be satisfiedfrom the clientrsquos 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 V997888rarr C satisfies payment-order(C M TTP)In each clientrsquos opinion the client will satisfy the trans-

actions only if heshe gets both a payment-order responsefrom the merchant and a debit response from the paymentgateway However the responses must be from the previoustransaction made by the client All requests are sent to thetrusted third party

Merchantrsquos Fairness For a transaction to be satisfactory inthe merchantrsquos opinion the following requirements must besatisfied

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 V997888rarrM satisfies credit (M PG TTP)It can be seen from the above statements that the

merchant will satisfy a transaction if heshe has delivered orcommitted to deliver goods or services to clients as a resultof receiving a payment-order request from the client Thepayment has to be processed by the payment gateway Thepayment gateway must transfer the amount requested by themerchant to the account of themerchant prior to the deliveryof goods or services to the client

Payment Gatewayrsquos Fairness For a transaction to be sat-isfactory in the payment gatewayrsquos opinion the followingrequirements 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 V997888rarr 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 andmerchant Specifically the payment gateway must performactions according to the debit and credit requests made byboth the client and the merchant The payment gatewaytransfers or commits to deduct the amount requested by theclient and transfer the amount requested by the merchant tothe account of the merchant

33 Background Concept on the Secure Session Key GenerationTechnique In this section we will explain the concept of thesecure session key generation technique that is used in a phaseof our proposed protocols The topics that are extensivelydiscussed in symmetric encryptions are the secure sessionkey generation techniques Many researchers have presenteda secure session key generation technique used in their own

Wireless Communications and Mobile Computing 5

Session key3+D D = 1 -

Intermediate key generationRound n

Intermediate key generationRound 1

Preference key generation+C = B(+C-1 $+)

)+1D = B(=IH=(+-C>) )+

1D-1)

)+HD = B(=IH=()+H-1

-C>) )+HD-1)

Figure 1 Session key generator

papers [29 31ndash35] Among all the mentioned approaches[29] proposed a secure session key generation technique thatprevents key compromise attacks Moreover with the securesession key generation technique the parties do not need totransmit a key over the network In our paper we use [29]in introducing our protocols The methodology of [29] isdemonstrated below

Let us assume that party A and party B share 119870119860119861 DKm where 119870119860119861 stands for a long-term key DK stands fora distributed key and 119898 is a random number m is utilizedto indicate the number of keys that will be produced Theconc(M1 M2 M3) shows the concatenation of each of themessages M1 M2 and M3 respectively The secure sessionkey generation technique process is shown in Figure 1

After sharing 119870119860119861 DK m party A and party B create aset of preference keys 119870119894 where i = 1 m as follows 119870119894 =h(119870119894-1 DK) where1198700 =119870119860119861The set of119870119894will be applied as anorigin to invigorate session keys K and DK can be removedfrom the system

Next party A and party B generate sets of intermediatekeys to increase the difficulty for cryptanalysis Moreoverthis makes it more difficult to find the preference key ifthe session key is compromised In each round a new setof intermediate keys is produced Note that the higher thenumber of rounds performed the greater the security ofthe system The intermediate key generation is performedas follows 119868119870119909119895 = ℎ(119888119900119899119888(119868119870119909-1119872119894119889) 119868119870

119909119895-1) where 119909

specifies the number of rounds and j specifies the number of

intermediate keys that are generated j = 1 m 119868119870119909-1119872119894119889stands for the set of 119868119870119909-11198721198941198891 119868119870

119909-11198721198941198892 119868119870

119909-11198721198941198893

1198681198701199091198721198941198891 = 119898119894119889(1198681198701199091 119868119870119909119903119898) and 119903119898 is the remaining

number of intermediate keys in the set of 119868119870119909119895 1198681198701199091198721198941198892 =

119898119894119889(1198681198701199091198721198941198891 119868119870119909119903119898) 1198681198701199091198721198941198893 = 119898119894119889(1198681198701199091 119868119870

1199091198721198941198892)

11986811987011198721198941198891 = 1198701198721198941198891 11986811987011198721198941198891 = 1198701198721198941198892 and 119868119870

11198721198941198891 = 1198701198721198941198893

The generation of11987011987211989411988911198701198721198941198892 and1198701198721198941198893 is the same as thatof 1198681198701199091198721198941198891 1198681198701199091198721198941198892 and 1198681198701199091198721198941198893 respectively 119868119870119909119895-1 = 120593The output of the last round of intermediate key generationis considered as session keys SKj where j = 1 m whichis shown below 1198681198701198991 = 1198781198701 119868119870

1198992 = 1198781198702 119868119870

119899119898 = 119878119870119898

Party A and party B can then use SKj as a credential tosecure transactions as say an encryption key or as an inputto Message Authentication Codes

It can be obviously seen that the session key is createdpurely offline Each party can produce a set of session keysused to secure communication among themselves with norequirements to exchange credentials through the networkas a new session key is not transferred over the network

34 Registration Phase It is assumed that mobile deviceshave the software based on installation of our protocols Oncethe software is loaded the client needs to log on to thepayment system via a secure channel eg TLS (TransportLayer Security) The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119874DKCO 119898119862119874 with the mobile operator The client and themobile operator create a set of session keys SKCOj by usingthe secure session key generation technique proposed in [29]where j = 1 m

(2)The client establishes a TLS session and shares KCTTPDKCTTP mCTTP with TTP The client and TTP create a set ofsession keys SKCTTPj using the secure session key generationtechnique proposed in [29] where j = 1 m

35 Purchase Credit Request Phase In this section before theclient pays for goods or services the client purchases a top-up cash card The client runs the client software from hisherdevice Next he or she fills in the serial number of the top-upcash card and sends the following to the mobile operator

M1 C997888rarrO 119868119863119862 SN1198791 h(SN CLT1198791 SKCOj) h(119868119863119862SN CLT 1198791)119878119870119862119879119879119875119895

M2 O 997888rarr TTP h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 h(CLT1198791 1198792)119878119870119874119879119879119875119895

M3 TTP 997888rarr O h(IDC SN CLT 1198791) h(CLT 11987911198792)119878119870119862119879119879119875119895+1 h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1

M4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SNCLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1

In message M1 the client sends message IDC SN 1198791h(SN CLT 1198791 SKCOj) h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 to themobile operator The message h(SN CLT 1198791 SKCOj) is con-sidered as Message Authentication Code (MAC) which is anauthentication token between the client and the mobile oper-atorMoreover in order to guarantee information correctnessand to defend against erroneous information alteration ordestruction the message h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 willbe transmitted to TTP via the mobile operator Note that 1198791

6 Wireless Communications and Mobile Computing

Table 2 Symbols and abbreviations

Symbol Definition Bits

IDMS1IDMS2IMSI International Mobile Subscriber Identity ofMobile station 80

MACH Message Authentication CodeHash function 160ReqNoSeq Request number 8DK Delegation key 128Order msg Product order 160PriceP Cost of product 64

Withdraw Req Msg Withdraw Resp Msg The customer pays the desired price from hisbank 64

Ack A validation message to the customer 64FS Financial server identification 128Name Name of payer 160NationalID National Identification 104RandomPublicKey The ephemeral public key 128PayeeMobNo Mobile phone number of payee 80Value Digital currency 80IDPRIDPEIDCIDM Identification of Payer PayeeClientMerchant 80Payee Id Identification of Payee 80BI Bank information 128Amt Amount in payerrsquos bank account 64SKBSKPGSKIBSKPGIBSKPGABSKCOSKCTTPSKOTTPSKMTTPSKCMSKMOSKABKPasskeyUAKey

Session Key 128

TSPGTSIBTSBTSPR TT1T2T3T4T5 Timestamp 80NPGNIBNPRNB Nonce 128Payment Notify Payment acknowledgment 128PIPR Payment Information of payer 128TID Transaction ID 128ExpTExpiryKeyExpiry Expiry of primary key 64NSNC Random number 128CertSAG Certificate of Security Access Gateway 40ID ME Mobile phone Number 80CME Certificate of mobile phone 40SN Serial number of the top-up cash card 112CLT Credit limit 40CLRM Remaining credits 40OIOrder Message Order information 160

(YesNo) Purchase credit requestMessage status ofmerchant verifies the goods or services 24

(AcceptReject)Req Msg Payment status 48

denotes the timestamp for the time when the purchase creditis requested and to prevent a replay attack

In message M2 upon receiving this message from theclient the mobile operator sends the message h(IDC SNCLT 1198791)119878119870119862119879119879119875119895 h(CLT 1198791 1198792)119878119870119874119879119879119875119895 to TTP

In message M3 TTP decrypts this message with SKCTTPjand SKOTTPj and keeps the hash value TTP encrypts the hashvalue of h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 with

SKCTTPj+1and encrypts the hash value of h(IDC SN CLT1198791)h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1 with SKOTTPj+1 Then TTP sends allthe messages to the mobile operator Note that 1198792 denotes thetimestamp when the purchase credit is sent to a client and toprevent a replay attack

In message M4 the mobile operator generates messageh(CLT 1198791 1198792 SKCOj+1) which is an authentication tokenbetween the client and the mobile operator Moreover this

Wireless Communications and Mobile Computing 7

Table 3 Cryptographic operation functions

Functions DefinitionDK Encryption with delegation KeySK Encryption with symmetric key encryptionPub Encryption with asymmetric key encryptionf1 Cryptographic function to generate DKf2 Message Authentication Code functionf3 Hash function

Table 4 Message length of our protocols

Message Purchase Credit (Bytes) Making Payment(Bytes)

M1 96 126M2 64 80M3 96 64M4 88 96M5 - 192M6 - 64M7 - 112Total (Bytes) 344 734

message is created in order to guarantee information correct-ness and to defend against erroneous information alterationor destruction Then the mobile operator sends messageh(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 to the client

In the above messages the client supplies the serialnumber of the top-up cash card together with the requestedcredit limit to themobile operatorMobile operators can inferthe credit limit from the serial number given that the serialnumber is from a prepaid cash card Note that serial numberscan also track the credit limit up to which the client is allowedto buy goods or services from the mobile operator Notethat an attacker cannot modify the serial number when theserial number is transmitted in clear text as it is key-hashedin h(SN CLT 1198791 SKCOj) which is a MAC with SKCOj thatis shared between the client and the mobile operator Afterreceiving the demand from the client the mobile operatoradds the credit limit value to the clientrsquos account and sendsa message to the client The mobile operator acknowledgesthe increment of the clientrsquos credit limit During this phasethe client utilizes a top-up cash card in case they do not haveenough credit to make the payment phase

36Making Payment Phase At the beginning of the protocolthe client and the merchant need to establish accounts withtheir mobile operator The mobile operator will deduct acertain amount of value that is purchased by the client whenheshe opens the account There are two major functions onthe clientrsquos side application to operate searching and MakingPayment for goods or services The merchant is the sellerof the goods or services on a mobile portal operated by themobile operator The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119872DKCM119898119862119872with themerchantThe client and themerchant

create a set of session keys SKCMj by using the secure sessionkey generation technique proposed in [29] where j = 1 m

(2) The merchant establishes a TLS session and shares119870119872119874 DKMO119898119872119874 with the mobile operator The merchantand the mobile operator create a set of session keys SKMOjusing the secure session key generation technique proposedin [29] where j = 1 m

(3) The merchant establishes a TLS session and sharesKMTTP DKMTTP mMTTP with TTP They both establish aset of session keys SKMTTPj using the secure session keygeneration technique proposed in [29] where j = 1 m

(4) The client browses lists of goods or services via theapplication on his or her device When the goods or serviceshave been added to the cart the client can make a paymentby the protocol described below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895Otherwise the mobile operator terminates the clientrsquos

requestM5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

In the case of message M1 the client sends messageIDC T IDM OI T h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OIT)119878119870119862119879119879119875119895 to the mobile operator The message IDM OIT h(OI SKCMj)119878119870119862119874119895 is encrypted with SKCOj which isthe session key shared between the client and the mobileoperator for the mobile operation to verify authenticity ofthe client It can be noted that the mobile operator doesnot know the session key SKCMj in order to construct themessage h(OI SKCMj) since it cannot generate thismessage byitself This message h(OI SKCMj) is considered as a MessageAuthentication Code (MAC) which is used to guaranteeinformation correctness and to defend against erroneousinformation alteration or destruction Moreover it enablesthe merchant to verify authenticity of the client The messageh(IDC IDM OI T)119878119870119862119879119879119875119895 will be transmitted to TTP viathe mobile operator It should be noted that 119879 denotes thetimestamp when the payment is requested and to prevent areplay attack

In the case of message M2 upon receiving the messagefrom the client the mobile operator sends message OI h(OISKCMj) h(OI SKCOj+1) T119878119870119872119874119895 to the merchant to verify theauthenticity of the mobile operator The hash value of h(OISKCMj) indicates that the mobile operator does not know thesession key SKCMj that is used to construct the message h(OISKCMj) since it cannot generate this message by itself

8 Wireless Communications and Mobile Computing

Table 5 SMS overhead of our protocols

Session SMS OverheadBytes 7-Bit ASCII (160 Byte) 8-Bit ASCII (140 Byte)

Purchase CreditM1 96 60 6875M4 88 55 6285

Making PaymentM1 126 7875 90M7 112 70 80

Table 6 Comparison of cryptographic operations

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Making PaymentSymmetric Encryption 6 - - 3 2 5 9 3 4 10Asymmetric Encryption - 4 3 4 4 - - 5 - -Message Authentication Code 3 - - 3 - - - 2 2 4Hash Function - - - - 4 2 1 - 2 3Number of Messages 9 6 5 6 6 7 9 6 4 7Number of Parties 4 4 2 5 3 3 4 5 3 4

Table 7 Comparison of energy consumption

AES (121 120583Jbyte) RSA (5465 120583Jbyte) HMAC (116 120583Jbyte) SHA1 (076 120583Jbyte) Total (120583Jbyte)[1] 726 0 348 0 1074[5] 0 2186 0 0 2186[6] 0 16395 0 0 16395[7] 363 2186 348 0 219311[8] 242 2186 0 304 219146[3] 605 0 0 152 757[9] 1089 0 0 076 1165[25] 363 27325 232 0 27385Purchase Credit 484 0 232 152 868Making Payment 121 0 464 228 1902

Table 8 Communication complexity

Protocol Communication cost (bits)

[1] (1)+(2)+(3)+(4)+(5)+(6)+(7)+(8)+(9)=(80+80+160+24)+(80+80+80+80+160+160)+(80+80+80)+(80)+(80+160+64)+(80+24)+(80+24+64+128)+(80)+(24+80)=2192lowastn

[5] (1)+(2)+(3)+(4)+(5)+(6)= (160)+(64+160+80)+(64+48)+(64)+(64)+(64)=768lowastn[6] (1)+(2)+(3)+(4)+(5)=(128)+(160+80+104+160+64+128)+(128)+(128)+(80+80+128+128)=1496lowastn

[7] (1)+(2)+(3)+(4)+(5)+(6)=80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)+(80+64+128+160)+(128+64+80+128+160)+(128+80+128)=3728lowastn

[8] (1)+(2)+(3)+(4)+(5)= (40+80+128+24)+(80)+(40+160)+(128+128+64+160)+(128)=1160lowastn[3] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn[9] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn

[25](1)+(2)+(3)+(4)+(5)+(6)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)

+(128+80+128+128+80+128)+(160+128+128+128+128+80)+(160+128+128+128+128+80)+(128+80+128)=4592lowastn

MakingPayment

(1)+(2)+(3)+(4)+(5)+(6)+(7)=80+80+80+160+80+160+160)+(160+160+160+80)+(24+160+160)+(160+160+160)+(160+160+160+160+160+160+160+160+160)+(160+160+160)

+(48+24+40+160+160+160+160+160)=5016lowastn

Wireless Communications and Mobile Computing 9

Table 9 Computational complexity

Protocol Computational cost[1] f2 f2 SK SK f2 f1 DK f1 SK SK DK=11lowastn[5] Pub Pub Pub Pub=4lowastn[6] Pub f3 Pub SK=4lowastn[7] Pub Pub Pub Pub f2 SK f2 SK f2 SK=10lowastn[8] f3 Pub f3 Pub f2 Pub Pub SK=8lowastn[3] f2 SK SK f1 f2 f1 DK=7lowastn[9] f2 SK SK f1 f2 f1 DK=7lowastn

[25] Pub Pub Pub Pub Pub SK f2 SK f2SK=10lowastn

MakingPayment

f2 SK f3 SK f3 SK f2 SK f3 SK f3 SK SKSK SK f2 SK=17lowastn

In the case of message M3 after receiving the messagefrom the mobile operator the merchant verifies the goodsor services If these are valid a Yes message will be sent tothe mobile operator but if they are invalid a No messagewill be sent to the mobile operator and then the mobileoperator will terminate the clientrsquos request The merchantthen sends the message YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1h(Yes OI)119878119870119872119879119879119875119895 to the mobile operator The messagethat contains YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1 is for themobile operator to verify the authenticity of the merchantIt should be noted that the mobile operator does not knowthe session key SKCMj+1 that is used to construct the messageh(Yes OI SKCMj+1) since it cannot generate this message byitself This message contains h(YesNo OI SKCMj+1) in orderto guarantee information correctness and to defend againsterroneous information alteration or destructionThemessageh(Yes OI)119878119870119872119879119879119875119895 will be transmitted to TTP via the mobileoperator

In the case of message M4 upon receiving this messagefrom the merchant the mobile operator checks the creditbalance and compares it with the requested amount If theclient has enough credit the mobile operator will reply withan Accept message to the client If not the mobile operatorwill reply with a Reject message and then the client has toreturn to the Purchase Credit Request Phase The mobileoperator then sends message h(IDC IDM OI T)119878119870119862119879119879119875119895h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895 toTTP

In the case of message M5 after receiving the mes-sage from the mobile operator TTP decrypts the messageh(IDC IDM OI T)119878119870119862119879119879119875119895 with SKCTTPj h(AcceptRejectOI CLRM)119878119870119874119879119879119875119895 with SKOTTPj and h(Yes OI)119878119870119872119879119879119875119895with SKMTTPj and it keeps the decrypted message toitself Then TTP encrypts the message h(IDC IDM OIT) h(AcceptReject OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 withSKCTTPj+1 h(IDC IDM OI T) h(AcceptReject OI CLRM)h(Yes OI)119878119870119874119879119879119875119895+1 and encrypts themessage with SKOTTPj+1and h(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119872119879119879119875119895+1TTP also encrypts themessage with SKMTTPj+1and sends all the messages to the mobile operator

In the case of message M6 the mobile operator for-wards the message h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1 which is encrypted by TTPwithSKMTTPj+1 to the merchant

In the case of message M7 the mobile operator encryptsmessage one AcceptReject Yes CLRM h(Yes OI SKCMj+1)h(OI SKMOj+1)119878119870119862119874119895+1 with SK119862119874119895+1 while the messageh(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119862119879119879119875119895+1 is encrypted by TTP with SK119862119879119879119875119895+1 to theclient The message that contains AcceptReject Yes CLRMh(YesNo OI SKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 is for the clientto verify the authenticity of themobile operator It can be seenthat the mobile operator cannot deny that the message hasoriginated from himher because only the mobile operatorpossesses both SKMOj +1 and SKCOj+1 This means that themobile operator is the only one that can generate thismessage The hash value of h(YesNo OI SKCMj+1) notes thatthe mobile operator does not know the session key SK119862119872119895+1that is used to construct the message h(Yes OI SKCMj+1) andthe client to verify the authenticity of the merchant since itcannot generate this message by itself

37 Dispute Resolution Phase After the transaction is com-plete if the client is not satisfied with the transaction heshecan request a dispute resolution with the verifier The disputeresolution protocols are composed of two subprotocolsPurchase Credit Request Phase and Making Payment PhaseConsider the protocols below

371 Purchase Credit Request Theclient sends the hash valueh(IDC SN CLT 1198791) h(CLT 1198791 1198792) of the transaction to theverifier Upon receiving the hash value from the client theverifier sends the requested hash value ofTTP After receivingthe hash value fromTTP the verifier compares the hash valuefrom the client with a hash value from TTP If the hash valuesdo not match the verifier rejects the clientrsquos request if notthe verifier sends a notification of dispute resolution to themobile operator to transfer the amount to the clientrsquos accountNote that the verifier stands for the external party and is aparty that is not relevant to the particular transaction

372 Making Payment The client sends the hash valueh(IDC IDM OI T) h (OI CLRM) h(YesNo OI) of thetransaction to the verifier Upon receiving the hash valuefrom the client the verifier sends the requested hash valueof TTP After receiving the hash value from TTP the verifiercompares the hash value from the client with a hash valuefrom TTP If the hash values do not match the verifier rejectsthe clientrsquos request if not the verifier sends a notificationof dispute resolution to the mobile operator to transfer theamount to the clientrsquos account and sends notification to themerchant Note that the verifier stands for the external partyand is a party that is not relevant to the particular transaction

It is obvious that in the Purchase Credit Request Phase(Section 35) and theMaking Payment Phase (Section 36) allmessages received by the TTP are only the hash values of thetransactional data Therefore it is not possible for the TTP to

10 Wireless Communications and Mobile Computing

Table 10 Storage complexity

Protocol Storage cost[1] (1)+(2)+(3)+(4)=(80+80+160+24)+(80+160+64)+(80+24=104)+(24+80)=856lowastn[5] (1)+(2)+(3)+(4)=(160)+(64+160+80)+(64+48)+(64)=640lowastn[6] (1)+(2)+(3)= (128)+(160+80+104+160+64+128)+(80+80+128+128)=1240lowastn[7] (1)+(2)+(3)=(80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)=2400lowastn[8] (1)+(2)+(3)=(40+80+128+24)+(128+128+64+160)+(128)=880lowastn[3] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn[9] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn

[25] (1)+(2)+(3)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)+(128+80+128+128+80+128)=2752lowastn

MakingPayment (1)+(2)=(80+80+80+160+80+160+160)+(48+24+40+160+160+160+160+160)=1712lowastn

Table 11 Comparison of mobile payment protocols

Protocol Type of Fairness Uses TTP TTP Type[1] No Fairness No Without TTP[5] No Fairness No Without TTP[6] No Fairness No Without TTP[7] No Fairness No Without TTP[8] No Fairness No Without TTP[3] No Fairness No Without TTP[9] Weak Fairness Yes Online[25] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

accessmeaningful information of the transactionThismakesour protocols have strong fairness

4 Discussion

41 Security Analysis (1) Brute force attacks for the comple-tion of a transaction of our protocols the session keys changeevery time and are not reused therefore it is difficult for theattacker to find the correct session key that is shared betweenparties In addition according to [29] a brute force attackis difficult to complete by applying an offline key generationtechnique

(2) Replay attack prevention the attacker intersects themessage and resends an old message Our protocols are usedonly once with a fresh timestamp so a replay attack can beprevented and is difficult to accomplish For further detailsabout this technique the reader is referred to [29]

(3) Message integrity the integrity of the message is themost important security property that any party can ensureso that the message guarantees information correctness andis defended against erroneous information alteration ordestruction during the transmission With our protocolseach message comprises a Message Authentication Code(MAC) value that ensures the recipient of the message andthe same recent key can be used to generate a newMACThereceived MAC is compared with the calculated MAC

(4) Mutual authentication this is used to check who theoriginator and the receiver of a message are Our protocolsdeployMACs and symmetric cryptographic operations Onlythe originator and the receiver who share the same key will beable to encrypt and decrypt their messages As a result of ourprotocols eachmessage can be used to identify the originatorand the receiver so that the client the merchant and themobile operator ensure mutual authentication Consider themessage below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client and the mobile operatorshare the session key SKCOj but the mobile operator cannotgenerate thismessage by himself or herself because themobileoperator cannot generate h(OI SKCMj) as the session keySKCMj is shared only between the merchant and the clientOnly the session keys SKCMj and SKCOj are known by theclient therefore guaranteeing that the client generated thismessage

(5)Man-in-the-middle attacks an attacker cannot imper-sonate a party by intercepting message passes in theseprotocolsWith the use of limited-use session keys and propercryptographic operations no confidential information isrevealed and the reuse of authentication information islimited In addition the session keys used in our protocolsare changed constantly using strong encryption techniques

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 5: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Wireless Communications and Mobile Computing 5

Session key3+D D = 1 -

Intermediate key generationRound n

Intermediate key generationRound 1

Preference key generation+C = B(+C-1 $+)

)+1D = B(=IH=(+-C>) )+

1D-1)

)+HD = B(=IH=()+H-1

-C>) )+HD-1)

Figure 1 Session key generator

papers [29 31ndash35] Among all the mentioned approaches[29] proposed a secure session key generation technique thatprevents key compromise attacks Moreover with the securesession key generation technique the parties do not need totransmit a key over the network In our paper we use [29]in introducing our protocols The methodology of [29] isdemonstrated below

Let us assume that party A and party B share 119870119860119861 DKm where 119870119860119861 stands for a long-term key DK stands fora distributed key and 119898 is a random number m is utilizedto indicate the number of keys that will be produced Theconc(M1 M2 M3) shows the concatenation of each of themessages M1 M2 and M3 respectively The secure sessionkey generation technique process is shown in Figure 1

After sharing 119870119860119861 DK m party A and party B create aset of preference keys 119870119894 where i = 1 m as follows 119870119894 =h(119870119894-1 DK) where1198700 =119870119860119861The set of119870119894will be applied as anorigin to invigorate session keys K and DK can be removedfrom the system

Next party A and party B generate sets of intermediatekeys to increase the difficulty for cryptanalysis Moreoverthis makes it more difficult to find the preference key ifthe session key is compromised In each round a new setof intermediate keys is produced Note that the higher thenumber of rounds performed the greater the security ofthe system The intermediate key generation is performedas follows 119868119870119909119895 = ℎ(119888119900119899119888(119868119870119909-1119872119894119889) 119868119870

119909119895-1) where 119909

specifies the number of rounds and j specifies the number of

intermediate keys that are generated j = 1 m 119868119870119909-1119872119894119889stands for the set of 119868119870119909-11198721198941198891 119868119870

119909-11198721198941198892 119868119870

119909-11198721198941198893

1198681198701199091198721198941198891 = 119898119894119889(1198681198701199091 119868119870119909119903119898) and 119903119898 is the remaining

number of intermediate keys in the set of 119868119870119909119895 1198681198701199091198721198941198892 =

119898119894119889(1198681198701199091198721198941198891 119868119870119909119903119898) 1198681198701199091198721198941198893 = 119898119894119889(1198681198701199091 119868119870

1199091198721198941198892)

11986811987011198721198941198891 = 1198701198721198941198891 11986811987011198721198941198891 = 1198701198721198941198892 and 119868119870

11198721198941198891 = 1198701198721198941198893

The generation of11987011987211989411988911198701198721198941198892 and1198701198721198941198893 is the same as thatof 1198681198701199091198721198941198891 1198681198701199091198721198941198892 and 1198681198701199091198721198941198893 respectively 119868119870119909119895-1 = 120593The output of the last round of intermediate key generationis considered as session keys SKj where j = 1 m whichis shown below 1198681198701198991 = 1198781198701 119868119870

1198992 = 1198781198702 119868119870

119899119898 = 119878119870119898

Party A and party B can then use SKj as a credential tosecure transactions as say an encryption key or as an inputto Message Authentication Codes

It can be obviously seen that the session key is createdpurely offline Each party can produce a set of session keysused to secure communication among themselves with norequirements to exchange credentials through the networkas a new session key is not transferred over the network

34 Registration Phase It is assumed that mobile deviceshave the software based on installation of our protocols Oncethe software is loaded the client needs to log on to thepayment system via a secure channel eg TLS (TransportLayer Security) The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119874DKCO 119898119862119874 with the mobile operator The client and themobile operator create a set of session keys SKCOj by usingthe secure session key generation technique proposed in [29]where j = 1 m

(2)The client establishes a TLS session and shares KCTTPDKCTTP mCTTP with TTP The client and TTP create a set ofsession keys SKCTTPj using the secure session key generationtechnique proposed in [29] where j = 1 m

35 Purchase Credit Request Phase In this section before theclient pays for goods or services the client purchases a top-up cash card The client runs the client software from hisherdevice Next he or she fills in the serial number of the top-upcash card and sends the following to the mobile operator

M1 C997888rarrO 119868119863119862 SN1198791 h(SN CLT1198791 SKCOj) h(119868119863119862SN CLT 1198791)119878119870119862119879119879119875119895

M2 O 997888rarr TTP h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 h(CLT1198791 1198792)119878119870119874119879119879119875119895

M3 TTP 997888rarr O h(IDC SN CLT 1198791) h(CLT 11987911198792)119878119870119862119879119879119875119895+1 h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1

M4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SNCLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1

In message M1 the client sends message IDC SN 1198791h(SN CLT 1198791 SKCOj) h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 to themobile operator The message h(SN CLT 1198791 SKCOj) is con-sidered as Message Authentication Code (MAC) which is anauthentication token between the client and the mobile oper-atorMoreover in order to guarantee information correctnessand to defend against erroneous information alteration ordestruction the message h(IDC SN CLT 1198791)119878119870119862119879119879119875119895 willbe transmitted to TTP via the mobile operator Note that 1198791

6 Wireless Communications and Mobile Computing

Table 2 Symbols and abbreviations

Symbol Definition Bits

IDMS1IDMS2IMSI International Mobile Subscriber Identity ofMobile station 80

MACH Message Authentication CodeHash function 160ReqNoSeq Request number 8DK Delegation key 128Order msg Product order 160PriceP Cost of product 64

Withdraw Req Msg Withdraw Resp Msg The customer pays the desired price from hisbank 64

Ack A validation message to the customer 64FS Financial server identification 128Name Name of payer 160NationalID National Identification 104RandomPublicKey The ephemeral public key 128PayeeMobNo Mobile phone number of payee 80Value Digital currency 80IDPRIDPEIDCIDM Identification of Payer PayeeClientMerchant 80Payee Id Identification of Payee 80BI Bank information 128Amt Amount in payerrsquos bank account 64SKBSKPGSKIBSKPGIBSKPGABSKCOSKCTTPSKOTTPSKMTTPSKCMSKMOSKABKPasskeyUAKey

Session Key 128

TSPGTSIBTSBTSPR TT1T2T3T4T5 Timestamp 80NPGNIBNPRNB Nonce 128Payment Notify Payment acknowledgment 128PIPR Payment Information of payer 128TID Transaction ID 128ExpTExpiryKeyExpiry Expiry of primary key 64NSNC Random number 128CertSAG Certificate of Security Access Gateway 40ID ME Mobile phone Number 80CME Certificate of mobile phone 40SN Serial number of the top-up cash card 112CLT Credit limit 40CLRM Remaining credits 40OIOrder Message Order information 160

(YesNo) Purchase credit requestMessage status ofmerchant verifies the goods or services 24

(AcceptReject)Req Msg Payment status 48

denotes the timestamp for the time when the purchase creditis requested and to prevent a replay attack

In message M2 upon receiving this message from theclient the mobile operator sends the message h(IDC SNCLT 1198791)119878119870119862119879119879119875119895 h(CLT 1198791 1198792)119878119870119874119879119879119875119895 to TTP

In message M3 TTP decrypts this message with SKCTTPjand SKOTTPj and keeps the hash value TTP encrypts the hashvalue of h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 with

SKCTTPj+1and encrypts the hash value of h(IDC SN CLT1198791)h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1 with SKOTTPj+1 Then TTP sends allthe messages to the mobile operator Note that 1198792 denotes thetimestamp when the purchase credit is sent to a client and toprevent a replay attack

In message M4 the mobile operator generates messageh(CLT 1198791 1198792 SKCOj+1) which is an authentication tokenbetween the client and the mobile operator Moreover this

Wireless Communications and Mobile Computing 7

Table 3 Cryptographic operation functions

Functions DefinitionDK Encryption with delegation KeySK Encryption with symmetric key encryptionPub Encryption with asymmetric key encryptionf1 Cryptographic function to generate DKf2 Message Authentication Code functionf3 Hash function

Table 4 Message length of our protocols

Message Purchase Credit (Bytes) Making Payment(Bytes)

M1 96 126M2 64 80M3 96 64M4 88 96M5 - 192M6 - 64M7 - 112Total (Bytes) 344 734

message is created in order to guarantee information correct-ness and to defend against erroneous information alterationor destruction Then the mobile operator sends messageh(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 to the client

In the above messages the client supplies the serialnumber of the top-up cash card together with the requestedcredit limit to themobile operatorMobile operators can inferthe credit limit from the serial number given that the serialnumber is from a prepaid cash card Note that serial numberscan also track the credit limit up to which the client is allowedto buy goods or services from the mobile operator Notethat an attacker cannot modify the serial number when theserial number is transmitted in clear text as it is key-hashedin h(SN CLT 1198791 SKCOj) which is a MAC with SKCOj thatis shared between the client and the mobile operator Afterreceiving the demand from the client the mobile operatoradds the credit limit value to the clientrsquos account and sendsa message to the client The mobile operator acknowledgesthe increment of the clientrsquos credit limit During this phasethe client utilizes a top-up cash card in case they do not haveenough credit to make the payment phase

36Making Payment Phase At the beginning of the protocolthe client and the merchant need to establish accounts withtheir mobile operator The mobile operator will deduct acertain amount of value that is purchased by the client whenheshe opens the account There are two major functions onthe clientrsquos side application to operate searching and MakingPayment for goods or services The merchant is the sellerof the goods or services on a mobile portal operated by themobile operator The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119872DKCM119898119862119872with themerchantThe client and themerchant

create a set of session keys SKCMj by using the secure sessionkey generation technique proposed in [29] where j = 1 m

(2) The merchant establishes a TLS session and shares119870119872119874 DKMO119898119872119874 with the mobile operator The merchantand the mobile operator create a set of session keys SKMOjusing the secure session key generation technique proposedin [29] where j = 1 m

(3) The merchant establishes a TLS session and sharesKMTTP DKMTTP mMTTP with TTP They both establish aset of session keys SKMTTPj using the secure session keygeneration technique proposed in [29] where j = 1 m

(4) The client browses lists of goods or services via theapplication on his or her device When the goods or serviceshave been added to the cart the client can make a paymentby the protocol described below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895Otherwise the mobile operator terminates the clientrsquos

requestM5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

In the case of message M1 the client sends messageIDC T IDM OI T h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OIT)119878119870119862119879119879119875119895 to the mobile operator The message IDM OIT h(OI SKCMj)119878119870119862119874119895 is encrypted with SKCOj which isthe session key shared between the client and the mobileoperator for the mobile operation to verify authenticity ofthe client It can be noted that the mobile operator doesnot know the session key SKCMj in order to construct themessage h(OI SKCMj) since it cannot generate thismessage byitself This message h(OI SKCMj) is considered as a MessageAuthentication Code (MAC) which is used to guaranteeinformation correctness and to defend against erroneousinformation alteration or destruction Moreover it enablesthe merchant to verify authenticity of the client The messageh(IDC IDM OI T)119878119870119862119879119879119875119895 will be transmitted to TTP viathe mobile operator It should be noted that 119879 denotes thetimestamp when the payment is requested and to prevent areplay attack

In the case of message M2 upon receiving the messagefrom the client the mobile operator sends message OI h(OISKCMj) h(OI SKCOj+1) T119878119870119872119874119895 to the merchant to verify theauthenticity of the mobile operator The hash value of h(OISKCMj) indicates that the mobile operator does not know thesession key SKCMj that is used to construct the message h(OISKCMj) since it cannot generate this message by itself

8 Wireless Communications and Mobile Computing

Table 5 SMS overhead of our protocols

Session SMS OverheadBytes 7-Bit ASCII (160 Byte) 8-Bit ASCII (140 Byte)

Purchase CreditM1 96 60 6875M4 88 55 6285

Making PaymentM1 126 7875 90M7 112 70 80

Table 6 Comparison of cryptographic operations

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Making PaymentSymmetric Encryption 6 - - 3 2 5 9 3 4 10Asymmetric Encryption - 4 3 4 4 - - 5 - -Message Authentication Code 3 - - 3 - - - 2 2 4Hash Function - - - - 4 2 1 - 2 3Number of Messages 9 6 5 6 6 7 9 6 4 7Number of Parties 4 4 2 5 3 3 4 5 3 4

Table 7 Comparison of energy consumption

AES (121 120583Jbyte) RSA (5465 120583Jbyte) HMAC (116 120583Jbyte) SHA1 (076 120583Jbyte) Total (120583Jbyte)[1] 726 0 348 0 1074[5] 0 2186 0 0 2186[6] 0 16395 0 0 16395[7] 363 2186 348 0 219311[8] 242 2186 0 304 219146[3] 605 0 0 152 757[9] 1089 0 0 076 1165[25] 363 27325 232 0 27385Purchase Credit 484 0 232 152 868Making Payment 121 0 464 228 1902

Table 8 Communication complexity

Protocol Communication cost (bits)

[1] (1)+(2)+(3)+(4)+(5)+(6)+(7)+(8)+(9)=(80+80+160+24)+(80+80+80+80+160+160)+(80+80+80)+(80)+(80+160+64)+(80+24)+(80+24+64+128)+(80)+(24+80)=2192lowastn

[5] (1)+(2)+(3)+(4)+(5)+(6)= (160)+(64+160+80)+(64+48)+(64)+(64)+(64)=768lowastn[6] (1)+(2)+(3)+(4)+(5)=(128)+(160+80+104+160+64+128)+(128)+(128)+(80+80+128+128)=1496lowastn

[7] (1)+(2)+(3)+(4)+(5)+(6)=80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)+(80+64+128+160)+(128+64+80+128+160)+(128+80+128)=3728lowastn

[8] (1)+(2)+(3)+(4)+(5)= (40+80+128+24)+(80)+(40+160)+(128+128+64+160)+(128)=1160lowastn[3] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn[9] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn

[25](1)+(2)+(3)+(4)+(5)+(6)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)

+(128+80+128+128+80+128)+(160+128+128+128+128+80)+(160+128+128+128+128+80)+(128+80+128)=4592lowastn

MakingPayment

(1)+(2)+(3)+(4)+(5)+(6)+(7)=80+80+80+160+80+160+160)+(160+160+160+80)+(24+160+160)+(160+160+160)+(160+160+160+160+160+160+160+160+160)+(160+160+160)

+(48+24+40+160+160+160+160+160)=5016lowastn

Wireless Communications and Mobile Computing 9

Table 9 Computational complexity

Protocol Computational cost[1] f2 f2 SK SK f2 f1 DK f1 SK SK DK=11lowastn[5] Pub Pub Pub Pub=4lowastn[6] Pub f3 Pub SK=4lowastn[7] Pub Pub Pub Pub f2 SK f2 SK f2 SK=10lowastn[8] f3 Pub f3 Pub f2 Pub Pub SK=8lowastn[3] f2 SK SK f1 f2 f1 DK=7lowastn[9] f2 SK SK f1 f2 f1 DK=7lowastn

[25] Pub Pub Pub Pub Pub SK f2 SK f2SK=10lowastn

MakingPayment

f2 SK f3 SK f3 SK f2 SK f3 SK f3 SK SKSK SK f2 SK=17lowastn

In the case of message M3 after receiving the messagefrom the mobile operator the merchant verifies the goodsor services If these are valid a Yes message will be sent tothe mobile operator but if they are invalid a No messagewill be sent to the mobile operator and then the mobileoperator will terminate the clientrsquos request The merchantthen sends the message YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1h(Yes OI)119878119870119872119879119879119875119895 to the mobile operator The messagethat contains YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1 is for themobile operator to verify the authenticity of the merchantIt should be noted that the mobile operator does not knowthe session key SKCMj+1 that is used to construct the messageh(Yes OI SKCMj+1) since it cannot generate this message byitself This message contains h(YesNo OI SKCMj+1) in orderto guarantee information correctness and to defend againsterroneous information alteration or destructionThemessageh(Yes OI)119878119870119872119879119879119875119895 will be transmitted to TTP via the mobileoperator

In the case of message M4 upon receiving this messagefrom the merchant the mobile operator checks the creditbalance and compares it with the requested amount If theclient has enough credit the mobile operator will reply withan Accept message to the client If not the mobile operatorwill reply with a Reject message and then the client has toreturn to the Purchase Credit Request Phase The mobileoperator then sends message h(IDC IDM OI T)119878119870119862119879119879119875119895h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895 toTTP

In the case of message M5 after receiving the mes-sage from the mobile operator TTP decrypts the messageh(IDC IDM OI T)119878119870119862119879119879119875119895 with SKCTTPj h(AcceptRejectOI CLRM)119878119870119874119879119879119875119895 with SKOTTPj and h(Yes OI)119878119870119872119879119879119875119895with SKMTTPj and it keeps the decrypted message toitself Then TTP encrypts the message h(IDC IDM OIT) h(AcceptReject OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 withSKCTTPj+1 h(IDC IDM OI T) h(AcceptReject OI CLRM)h(Yes OI)119878119870119874119879119879119875119895+1 and encrypts themessage with SKOTTPj+1and h(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119872119879119879119875119895+1TTP also encrypts themessage with SKMTTPj+1and sends all the messages to the mobile operator

In the case of message M6 the mobile operator for-wards the message h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1 which is encrypted by TTPwithSKMTTPj+1 to the merchant

In the case of message M7 the mobile operator encryptsmessage one AcceptReject Yes CLRM h(Yes OI SKCMj+1)h(OI SKMOj+1)119878119870119862119874119895+1 with SK119862119874119895+1 while the messageh(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119862119879119879119875119895+1 is encrypted by TTP with SK119862119879119879119875119895+1 to theclient The message that contains AcceptReject Yes CLRMh(YesNo OI SKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 is for the clientto verify the authenticity of themobile operator It can be seenthat the mobile operator cannot deny that the message hasoriginated from himher because only the mobile operatorpossesses both SKMOj +1 and SKCOj+1 This means that themobile operator is the only one that can generate thismessage The hash value of h(YesNo OI SKCMj+1) notes thatthe mobile operator does not know the session key SK119862119872119895+1that is used to construct the message h(Yes OI SKCMj+1) andthe client to verify the authenticity of the merchant since itcannot generate this message by itself

37 Dispute Resolution Phase After the transaction is com-plete if the client is not satisfied with the transaction heshecan request a dispute resolution with the verifier The disputeresolution protocols are composed of two subprotocolsPurchase Credit Request Phase and Making Payment PhaseConsider the protocols below

371 Purchase Credit Request Theclient sends the hash valueh(IDC SN CLT 1198791) h(CLT 1198791 1198792) of the transaction to theverifier Upon receiving the hash value from the client theverifier sends the requested hash value ofTTP After receivingthe hash value fromTTP the verifier compares the hash valuefrom the client with a hash value from TTP If the hash valuesdo not match the verifier rejects the clientrsquos request if notthe verifier sends a notification of dispute resolution to themobile operator to transfer the amount to the clientrsquos accountNote that the verifier stands for the external party and is aparty that is not relevant to the particular transaction

372 Making Payment The client sends the hash valueh(IDC IDM OI T) h (OI CLRM) h(YesNo OI) of thetransaction to the verifier Upon receiving the hash valuefrom the client the verifier sends the requested hash valueof TTP After receiving the hash value from TTP the verifiercompares the hash value from the client with a hash valuefrom TTP If the hash values do not match the verifier rejectsthe clientrsquos request if not the verifier sends a notificationof dispute resolution to the mobile operator to transfer theamount to the clientrsquos account and sends notification to themerchant Note that the verifier stands for the external partyand is a party that is not relevant to the particular transaction

It is obvious that in the Purchase Credit Request Phase(Section 35) and theMaking Payment Phase (Section 36) allmessages received by the TTP are only the hash values of thetransactional data Therefore it is not possible for the TTP to

10 Wireless Communications and Mobile Computing

Table 10 Storage complexity

Protocol Storage cost[1] (1)+(2)+(3)+(4)=(80+80+160+24)+(80+160+64)+(80+24=104)+(24+80)=856lowastn[5] (1)+(2)+(3)+(4)=(160)+(64+160+80)+(64+48)+(64)=640lowastn[6] (1)+(2)+(3)= (128)+(160+80+104+160+64+128)+(80+80+128+128)=1240lowastn[7] (1)+(2)+(3)=(80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)=2400lowastn[8] (1)+(2)+(3)=(40+80+128+24)+(128+128+64+160)+(128)=880lowastn[3] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn[9] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn

[25] (1)+(2)+(3)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)+(128+80+128+128+80+128)=2752lowastn

MakingPayment (1)+(2)=(80+80+80+160+80+160+160)+(48+24+40+160+160+160+160+160)=1712lowastn

Table 11 Comparison of mobile payment protocols

Protocol Type of Fairness Uses TTP TTP Type[1] No Fairness No Without TTP[5] No Fairness No Without TTP[6] No Fairness No Without TTP[7] No Fairness No Without TTP[8] No Fairness No Without TTP[3] No Fairness No Without TTP[9] Weak Fairness Yes Online[25] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

accessmeaningful information of the transactionThismakesour protocols have strong fairness

4 Discussion

41 Security Analysis (1) Brute force attacks for the comple-tion of a transaction of our protocols the session keys changeevery time and are not reused therefore it is difficult for theattacker to find the correct session key that is shared betweenparties In addition according to [29] a brute force attackis difficult to complete by applying an offline key generationtechnique

(2) Replay attack prevention the attacker intersects themessage and resends an old message Our protocols are usedonly once with a fresh timestamp so a replay attack can beprevented and is difficult to accomplish For further detailsabout this technique the reader is referred to [29]

(3) Message integrity the integrity of the message is themost important security property that any party can ensureso that the message guarantees information correctness andis defended against erroneous information alteration ordestruction during the transmission With our protocolseach message comprises a Message Authentication Code(MAC) value that ensures the recipient of the message andthe same recent key can be used to generate a newMACThereceived MAC is compared with the calculated MAC

(4) Mutual authentication this is used to check who theoriginator and the receiver of a message are Our protocolsdeployMACs and symmetric cryptographic operations Onlythe originator and the receiver who share the same key will beable to encrypt and decrypt their messages As a result of ourprotocols eachmessage can be used to identify the originatorand the receiver so that the client the merchant and themobile operator ensure mutual authentication Consider themessage below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client and the mobile operatorshare the session key SKCOj but the mobile operator cannotgenerate thismessage by himself or herself because themobileoperator cannot generate h(OI SKCMj) as the session keySKCMj is shared only between the merchant and the clientOnly the session keys SKCMj and SKCOj are known by theclient therefore guaranteeing that the client generated thismessage

(5)Man-in-the-middle attacks an attacker cannot imper-sonate a party by intercepting message passes in theseprotocolsWith the use of limited-use session keys and propercryptographic operations no confidential information isrevealed and the reuse of authentication information islimited In addition the session keys used in our protocolsare changed constantly using strong encryption techniques

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 6: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

6 Wireless Communications and Mobile Computing

Table 2 Symbols and abbreviations

Symbol Definition Bits

IDMS1IDMS2IMSI International Mobile Subscriber Identity ofMobile station 80

MACH Message Authentication CodeHash function 160ReqNoSeq Request number 8DK Delegation key 128Order msg Product order 160PriceP Cost of product 64

Withdraw Req Msg Withdraw Resp Msg The customer pays the desired price from hisbank 64

Ack A validation message to the customer 64FS Financial server identification 128Name Name of payer 160NationalID National Identification 104RandomPublicKey The ephemeral public key 128PayeeMobNo Mobile phone number of payee 80Value Digital currency 80IDPRIDPEIDCIDM Identification of Payer PayeeClientMerchant 80Payee Id Identification of Payee 80BI Bank information 128Amt Amount in payerrsquos bank account 64SKBSKPGSKIBSKPGIBSKPGABSKCOSKCTTPSKOTTPSKMTTPSKCMSKMOSKABKPasskeyUAKey

Session Key 128

TSPGTSIBTSBTSPR TT1T2T3T4T5 Timestamp 80NPGNIBNPRNB Nonce 128Payment Notify Payment acknowledgment 128PIPR Payment Information of payer 128TID Transaction ID 128ExpTExpiryKeyExpiry Expiry of primary key 64NSNC Random number 128CertSAG Certificate of Security Access Gateway 40ID ME Mobile phone Number 80CME Certificate of mobile phone 40SN Serial number of the top-up cash card 112CLT Credit limit 40CLRM Remaining credits 40OIOrder Message Order information 160

(YesNo) Purchase credit requestMessage status ofmerchant verifies the goods or services 24

(AcceptReject)Req Msg Payment status 48

denotes the timestamp for the time when the purchase creditis requested and to prevent a replay attack

In message M2 upon receiving this message from theclient the mobile operator sends the message h(IDC SNCLT 1198791)119878119870119862119879119879119875119895 h(CLT 1198791 1198792)119878119870119874119879119879119875119895 to TTP

In message M3 TTP decrypts this message with SKCTTPjand SKOTTPj and keeps the hash value TTP encrypts the hashvalue of h(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 with

SKCTTPj+1and encrypts the hash value of h(IDC SN CLT1198791)h(CLT 1198791 1198792)119878119870119874119879119879119875119895+1 with SKOTTPj+1 Then TTP sends allthe messages to the mobile operator Note that 1198792 denotes thetimestamp when the purchase credit is sent to a client and toprevent a replay attack

In message M4 the mobile operator generates messageh(CLT 1198791 1198792 SKCOj+1) which is an authentication tokenbetween the client and the mobile operator Moreover this

Wireless Communications and Mobile Computing 7

Table 3 Cryptographic operation functions

Functions DefinitionDK Encryption with delegation KeySK Encryption with symmetric key encryptionPub Encryption with asymmetric key encryptionf1 Cryptographic function to generate DKf2 Message Authentication Code functionf3 Hash function

Table 4 Message length of our protocols

Message Purchase Credit (Bytes) Making Payment(Bytes)

M1 96 126M2 64 80M3 96 64M4 88 96M5 - 192M6 - 64M7 - 112Total (Bytes) 344 734

message is created in order to guarantee information correct-ness and to defend against erroneous information alterationor destruction Then the mobile operator sends messageh(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 to the client

In the above messages the client supplies the serialnumber of the top-up cash card together with the requestedcredit limit to themobile operatorMobile operators can inferthe credit limit from the serial number given that the serialnumber is from a prepaid cash card Note that serial numberscan also track the credit limit up to which the client is allowedto buy goods or services from the mobile operator Notethat an attacker cannot modify the serial number when theserial number is transmitted in clear text as it is key-hashedin h(SN CLT 1198791 SKCOj) which is a MAC with SKCOj thatis shared between the client and the mobile operator Afterreceiving the demand from the client the mobile operatoradds the credit limit value to the clientrsquos account and sendsa message to the client The mobile operator acknowledgesthe increment of the clientrsquos credit limit During this phasethe client utilizes a top-up cash card in case they do not haveenough credit to make the payment phase

36Making Payment Phase At the beginning of the protocolthe client and the merchant need to establish accounts withtheir mobile operator The mobile operator will deduct acertain amount of value that is purchased by the client whenheshe opens the account There are two major functions onthe clientrsquos side application to operate searching and MakingPayment for goods or services The merchant is the sellerof the goods or services on a mobile portal operated by themobile operator The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119872DKCM119898119862119872with themerchantThe client and themerchant

create a set of session keys SKCMj by using the secure sessionkey generation technique proposed in [29] where j = 1 m

(2) The merchant establishes a TLS session and shares119870119872119874 DKMO119898119872119874 with the mobile operator The merchantand the mobile operator create a set of session keys SKMOjusing the secure session key generation technique proposedin [29] where j = 1 m

(3) The merchant establishes a TLS session and sharesKMTTP DKMTTP mMTTP with TTP They both establish aset of session keys SKMTTPj using the secure session keygeneration technique proposed in [29] where j = 1 m

(4) The client browses lists of goods or services via theapplication on his or her device When the goods or serviceshave been added to the cart the client can make a paymentby the protocol described below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895Otherwise the mobile operator terminates the clientrsquos

requestM5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

In the case of message M1 the client sends messageIDC T IDM OI T h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OIT)119878119870119862119879119879119875119895 to the mobile operator The message IDM OIT h(OI SKCMj)119878119870119862119874119895 is encrypted with SKCOj which isthe session key shared between the client and the mobileoperator for the mobile operation to verify authenticity ofthe client It can be noted that the mobile operator doesnot know the session key SKCMj in order to construct themessage h(OI SKCMj) since it cannot generate thismessage byitself This message h(OI SKCMj) is considered as a MessageAuthentication Code (MAC) which is used to guaranteeinformation correctness and to defend against erroneousinformation alteration or destruction Moreover it enablesthe merchant to verify authenticity of the client The messageh(IDC IDM OI T)119878119870119862119879119879119875119895 will be transmitted to TTP viathe mobile operator It should be noted that 119879 denotes thetimestamp when the payment is requested and to prevent areplay attack

In the case of message M2 upon receiving the messagefrom the client the mobile operator sends message OI h(OISKCMj) h(OI SKCOj+1) T119878119870119872119874119895 to the merchant to verify theauthenticity of the mobile operator The hash value of h(OISKCMj) indicates that the mobile operator does not know thesession key SKCMj that is used to construct the message h(OISKCMj) since it cannot generate this message by itself

8 Wireless Communications and Mobile Computing

Table 5 SMS overhead of our protocols

Session SMS OverheadBytes 7-Bit ASCII (160 Byte) 8-Bit ASCII (140 Byte)

Purchase CreditM1 96 60 6875M4 88 55 6285

Making PaymentM1 126 7875 90M7 112 70 80

Table 6 Comparison of cryptographic operations

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Making PaymentSymmetric Encryption 6 - - 3 2 5 9 3 4 10Asymmetric Encryption - 4 3 4 4 - - 5 - -Message Authentication Code 3 - - 3 - - - 2 2 4Hash Function - - - - 4 2 1 - 2 3Number of Messages 9 6 5 6 6 7 9 6 4 7Number of Parties 4 4 2 5 3 3 4 5 3 4

Table 7 Comparison of energy consumption

AES (121 120583Jbyte) RSA (5465 120583Jbyte) HMAC (116 120583Jbyte) SHA1 (076 120583Jbyte) Total (120583Jbyte)[1] 726 0 348 0 1074[5] 0 2186 0 0 2186[6] 0 16395 0 0 16395[7] 363 2186 348 0 219311[8] 242 2186 0 304 219146[3] 605 0 0 152 757[9] 1089 0 0 076 1165[25] 363 27325 232 0 27385Purchase Credit 484 0 232 152 868Making Payment 121 0 464 228 1902

Table 8 Communication complexity

Protocol Communication cost (bits)

[1] (1)+(2)+(3)+(4)+(5)+(6)+(7)+(8)+(9)=(80+80+160+24)+(80+80+80+80+160+160)+(80+80+80)+(80)+(80+160+64)+(80+24)+(80+24+64+128)+(80)+(24+80)=2192lowastn

[5] (1)+(2)+(3)+(4)+(5)+(6)= (160)+(64+160+80)+(64+48)+(64)+(64)+(64)=768lowastn[6] (1)+(2)+(3)+(4)+(5)=(128)+(160+80+104+160+64+128)+(128)+(128)+(80+80+128+128)=1496lowastn

[7] (1)+(2)+(3)+(4)+(5)+(6)=80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)+(80+64+128+160)+(128+64+80+128+160)+(128+80+128)=3728lowastn

[8] (1)+(2)+(3)+(4)+(5)= (40+80+128+24)+(80)+(40+160)+(128+128+64+160)+(128)=1160lowastn[3] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn[9] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn

[25](1)+(2)+(3)+(4)+(5)+(6)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)

+(128+80+128+128+80+128)+(160+128+128+128+128+80)+(160+128+128+128+128+80)+(128+80+128)=4592lowastn

MakingPayment

(1)+(2)+(3)+(4)+(5)+(6)+(7)=80+80+80+160+80+160+160)+(160+160+160+80)+(24+160+160)+(160+160+160)+(160+160+160+160+160+160+160+160+160)+(160+160+160)

+(48+24+40+160+160+160+160+160)=5016lowastn

Wireless Communications and Mobile Computing 9

Table 9 Computational complexity

Protocol Computational cost[1] f2 f2 SK SK f2 f1 DK f1 SK SK DK=11lowastn[5] Pub Pub Pub Pub=4lowastn[6] Pub f3 Pub SK=4lowastn[7] Pub Pub Pub Pub f2 SK f2 SK f2 SK=10lowastn[8] f3 Pub f3 Pub f2 Pub Pub SK=8lowastn[3] f2 SK SK f1 f2 f1 DK=7lowastn[9] f2 SK SK f1 f2 f1 DK=7lowastn

[25] Pub Pub Pub Pub Pub SK f2 SK f2SK=10lowastn

MakingPayment

f2 SK f3 SK f3 SK f2 SK f3 SK f3 SK SKSK SK f2 SK=17lowastn

In the case of message M3 after receiving the messagefrom the mobile operator the merchant verifies the goodsor services If these are valid a Yes message will be sent tothe mobile operator but if they are invalid a No messagewill be sent to the mobile operator and then the mobileoperator will terminate the clientrsquos request The merchantthen sends the message YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1h(Yes OI)119878119870119872119879119879119875119895 to the mobile operator The messagethat contains YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1 is for themobile operator to verify the authenticity of the merchantIt should be noted that the mobile operator does not knowthe session key SKCMj+1 that is used to construct the messageh(Yes OI SKCMj+1) since it cannot generate this message byitself This message contains h(YesNo OI SKCMj+1) in orderto guarantee information correctness and to defend againsterroneous information alteration or destructionThemessageh(Yes OI)119878119870119872119879119879119875119895 will be transmitted to TTP via the mobileoperator

In the case of message M4 upon receiving this messagefrom the merchant the mobile operator checks the creditbalance and compares it with the requested amount If theclient has enough credit the mobile operator will reply withan Accept message to the client If not the mobile operatorwill reply with a Reject message and then the client has toreturn to the Purchase Credit Request Phase The mobileoperator then sends message h(IDC IDM OI T)119878119870119862119879119879119875119895h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895 toTTP

In the case of message M5 after receiving the mes-sage from the mobile operator TTP decrypts the messageh(IDC IDM OI T)119878119870119862119879119879119875119895 with SKCTTPj h(AcceptRejectOI CLRM)119878119870119874119879119879119875119895 with SKOTTPj and h(Yes OI)119878119870119872119879119879119875119895with SKMTTPj and it keeps the decrypted message toitself Then TTP encrypts the message h(IDC IDM OIT) h(AcceptReject OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 withSKCTTPj+1 h(IDC IDM OI T) h(AcceptReject OI CLRM)h(Yes OI)119878119870119874119879119879119875119895+1 and encrypts themessage with SKOTTPj+1and h(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119872119879119879119875119895+1TTP also encrypts themessage with SKMTTPj+1and sends all the messages to the mobile operator

In the case of message M6 the mobile operator for-wards the message h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1 which is encrypted by TTPwithSKMTTPj+1 to the merchant

In the case of message M7 the mobile operator encryptsmessage one AcceptReject Yes CLRM h(Yes OI SKCMj+1)h(OI SKMOj+1)119878119870119862119874119895+1 with SK119862119874119895+1 while the messageh(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119862119879119879119875119895+1 is encrypted by TTP with SK119862119879119879119875119895+1 to theclient The message that contains AcceptReject Yes CLRMh(YesNo OI SKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 is for the clientto verify the authenticity of themobile operator It can be seenthat the mobile operator cannot deny that the message hasoriginated from himher because only the mobile operatorpossesses both SKMOj +1 and SKCOj+1 This means that themobile operator is the only one that can generate thismessage The hash value of h(YesNo OI SKCMj+1) notes thatthe mobile operator does not know the session key SK119862119872119895+1that is used to construct the message h(Yes OI SKCMj+1) andthe client to verify the authenticity of the merchant since itcannot generate this message by itself

37 Dispute Resolution Phase After the transaction is com-plete if the client is not satisfied with the transaction heshecan request a dispute resolution with the verifier The disputeresolution protocols are composed of two subprotocolsPurchase Credit Request Phase and Making Payment PhaseConsider the protocols below

371 Purchase Credit Request Theclient sends the hash valueh(IDC SN CLT 1198791) h(CLT 1198791 1198792) of the transaction to theverifier Upon receiving the hash value from the client theverifier sends the requested hash value ofTTP After receivingthe hash value fromTTP the verifier compares the hash valuefrom the client with a hash value from TTP If the hash valuesdo not match the verifier rejects the clientrsquos request if notthe verifier sends a notification of dispute resolution to themobile operator to transfer the amount to the clientrsquos accountNote that the verifier stands for the external party and is aparty that is not relevant to the particular transaction

372 Making Payment The client sends the hash valueh(IDC IDM OI T) h (OI CLRM) h(YesNo OI) of thetransaction to the verifier Upon receiving the hash valuefrom the client the verifier sends the requested hash valueof TTP After receiving the hash value from TTP the verifiercompares the hash value from the client with a hash valuefrom TTP If the hash values do not match the verifier rejectsthe clientrsquos request if not the verifier sends a notificationof dispute resolution to the mobile operator to transfer theamount to the clientrsquos account and sends notification to themerchant Note that the verifier stands for the external partyand is a party that is not relevant to the particular transaction

It is obvious that in the Purchase Credit Request Phase(Section 35) and theMaking Payment Phase (Section 36) allmessages received by the TTP are only the hash values of thetransactional data Therefore it is not possible for the TTP to

10 Wireless Communications and Mobile Computing

Table 10 Storage complexity

Protocol Storage cost[1] (1)+(2)+(3)+(4)=(80+80+160+24)+(80+160+64)+(80+24=104)+(24+80)=856lowastn[5] (1)+(2)+(3)+(4)=(160)+(64+160+80)+(64+48)+(64)=640lowastn[6] (1)+(2)+(3)= (128)+(160+80+104+160+64+128)+(80+80+128+128)=1240lowastn[7] (1)+(2)+(3)=(80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)=2400lowastn[8] (1)+(2)+(3)=(40+80+128+24)+(128+128+64+160)+(128)=880lowastn[3] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn[9] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn

[25] (1)+(2)+(3)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)+(128+80+128+128+80+128)=2752lowastn

MakingPayment (1)+(2)=(80+80+80+160+80+160+160)+(48+24+40+160+160+160+160+160)=1712lowastn

Table 11 Comparison of mobile payment protocols

Protocol Type of Fairness Uses TTP TTP Type[1] No Fairness No Without TTP[5] No Fairness No Without TTP[6] No Fairness No Without TTP[7] No Fairness No Without TTP[8] No Fairness No Without TTP[3] No Fairness No Without TTP[9] Weak Fairness Yes Online[25] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

accessmeaningful information of the transactionThismakesour protocols have strong fairness

4 Discussion

41 Security Analysis (1) Brute force attacks for the comple-tion of a transaction of our protocols the session keys changeevery time and are not reused therefore it is difficult for theattacker to find the correct session key that is shared betweenparties In addition according to [29] a brute force attackis difficult to complete by applying an offline key generationtechnique

(2) Replay attack prevention the attacker intersects themessage and resends an old message Our protocols are usedonly once with a fresh timestamp so a replay attack can beprevented and is difficult to accomplish For further detailsabout this technique the reader is referred to [29]

(3) Message integrity the integrity of the message is themost important security property that any party can ensureso that the message guarantees information correctness andis defended against erroneous information alteration ordestruction during the transmission With our protocolseach message comprises a Message Authentication Code(MAC) value that ensures the recipient of the message andthe same recent key can be used to generate a newMACThereceived MAC is compared with the calculated MAC

(4) Mutual authentication this is used to check who theoriginator and the receiver of a message are Our protocolsdeployMACs and symmetric cryptographic operations Onlythe originator and the receiver who share the same key will beable to encrypt and decrypt their messages As a result of ourprotocols eachmessage can be used to identify the originatorand the receiver so that the client the merchant and themobile operator ensure mutual authentication Consider themessage below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client and the mobile operatorshare the session key SKCOj but the mobile operator cannotgenerate thismessage by himself or herself because themobileoperator cannot generate h(OI SKCMj) as the session keySKCMj is shared only between the merchant and the clientOnly the session keys SKCMj and SKCOj are known by theclient therefore guaranteeing that the client generated thismessage

(5)Man-in-the-middle attacks an attacker cannot imper-sonate a party by intercepting message passes in theseprotocolsWith the use of limited-use session keys and propercryptographic operations no confidential information isrevealed and the reuse of authentication information islimited In addition the session keys used in our protocolsare changed constantly using strong encryption techniques

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 7: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Wireless Communications and Mobile Computing 7

Table 3 Cryptographic operation functions

Functions DefinitionDK Encryption with delegation KeySK Encryption with symmetric key encryptionPub Encryption with asymmetric key encryptionf1 Cryptographic function to generate DKf2 Message Authentication Code functionf3 Hash function

Table 4 Message length of our protocols

Message Purchase Credit (Bytes) Making Payment(Bytes)

M1 96 126M2 64 80M3 96 64M4 88 96M5 - 192M6 - 64M7 - 112Total (Bytes) 344 734

message is created in order to guarantee information correct-ness and to defend against erroneous information alterationor destruction Then the mobile operator sends messageh(IDC SN CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1 to the client

In the above messages the client supplies the serialnumber of the top-up cash card together with the requestedcredit limit to themobile operatorMobile operators can inferthe credit limit from the serial number given that the serialnumber is from a prepaid cash card Note that serial numberscan also track the credit limit up to which the client is allowedto buy goods or services from the mobile operator Notethat an attacker cannot modify the serial number when theserial number is transmitted in clear text as it is key-hashedin h(SN CLT 1198791 SKCOj) which is a MAC with SKCOj thatis shared between the client and the mobile operator Afterreceiving the demand from the client the mobile operatoradds the credit limit value to the clientrsquos account and sendsa message to the client The mobile operator acknowledgesthe increment of the clientrsquos credit limit During this phasethe client utilizes a top-up cash card in case they do not haveenough credit to make the payment phase

36Making Payment Phase At the beginning of the protocolthe client and the merchant need to establish accounts withtheir mobile operator The mobile operator will deduct acertain amount of value that is purchased by the client whenheshe opens the account There are two major functions onthe clientrsquos side application to operate searching and MakingPayment for goods or services The merchant is the sellerof the goods or services on a mobile portal operated by themobile operator The protocol details are as follows

(1) The client establishes a TLS session and shares 119870119862119872DKCM119898119862119872with themerchantThe client and themerchant

create a set of session keys SKCMj by using the secure sessionkey generation technique proposed in [29] where j = 1 m

(2) The merchant establishes a TLS session and shares119870119872119874 DKMO119898119872119874 with the mobile operator The merchantand the mobile operator create a set of session keys SKMOjusing the secure session key generation technique proposedin [29] where j = 1 m

(3) The merchant establishes a TLS session and sharesKMTTP DKMTTP mMTTP with TTP They both establish aset of session keys SKMTTPj using the secure session keygeneration technique proposed in [29] where j = 1 m

(4) The client browses lists of goods or services via theapplication on his or her device When the goods or serviceshave been added to the cart the client can make a paymentby the protocol described below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895Otherwise the mobile operator terminates the clientrsquos

requestM5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

In the case of message M1 the client sends messageIDC T IDM OI T h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OIT)119878119870119862119879119879119875119895 to the mobile operator The message IDM OIT h(OI SKCMj)119878119870119862119874119895 is encrypted with SKCOj which isthe session key shared between the client and the mobileoperator for the mobile operation to verify authenticity ofthe client It can be noted that the mobile operator doesnot know the session key SKCMj in order to construct themessage h(OI SKCMj) since it cannot generate thismessage byitself This message h(OI SKCMj) is considered as a MessageAuthentication Code (MAC) which is used to guaranteeinformation correctness and to defend against erroneousinformation alteration or destruction Moreover it enablesthe merchant to verify authenticity of the client The messageh(IDC IDM OI T)119878119870119862119879119879119875119895 will be transmitted to TTP viathe mobile operator It should be noted that 119879 denotes thetimestamp when the payment is requested and to prevent areplay attack

In the case of message M2 upon receiving the messagefrom the client the mobile operator sends message OI h(OISKCMj) h(OI SKCOj+1) T119878119870119872119874119895 to the merchant to verify theauthenticity of the mobile operator The hash value of h(OISKCMj) indicates that the mobile operator does not know thesession key SKCMj that is used to construct the message h(OISKCMj) since it cannot generate this message by itself

8 Wireless Communications and Mobile Computing

Table 5 SMS overhead of our protocols

Session SMS OverheadBytes 7-Bit ASCII (160 Byte) 8-Bit ASCII (140 Byte)

Purchase CreditM1 96 60 6875M4 88 55 6285

Making PaymentM1 126 7875 90M7 112 70 80

Table 6 Comparison of cryptographic operations

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Making PaymentSymmetric Encryption 6 - - 3 2 5 9 3 4 10Asymmetric Encryption - 4 3 4 4 - - 5 - -Message Authentication Code 3 - - 3 - - - 2 2 4Hash Function - - - - 4 2 1 - 2 3Number of Messages 9 6 5 6 6 7 9 6 4 7Number of Parties 4 4 2 5 3 3 4 5 3 4

Table 7 Comparison of energy consumption

AES (121 120583Jbyte) RSA (5465 120583Jbyte) HMAC (116 120583Jbyte) SHA1 (076 120583Jbyte) Total (120583Jbyte)[1] 726 0 348 0 1074[5] 0 2186 0 0 2186[6] 0 16395 0 0 16395[7] 363 2186 348 0 219311[8] 242 2186 0 304 219146[3] 605 0 0 152 757[9] 1089 0 0 076 1165[25] 363 27325 232 0 27385Purchase Credit 484 0 232 152 868Making Payment 121 0 464 228 1902

Table 8 Communication complexity

Protocol Communication cost (bits)

[1] (1)+(2)+(3)+(4)+(5)+(6)+(7)+(8)+(9)=(80+80+160+24)+(80+80+80+80+160+160)+(80+80+80)+(80)+(80+160+64)+(80+24)+(80+24+64+128)+(80)+(24+80)=2192lowastn

[5] (1)+(2)+(3)+(4)+(5)+(6)= (160)+(64+160+80)+(64+48)+(64)+(64)+(64)=768lowastn[6] (1)+(2)+(3)+(4)+(5)=(128)+(160+80+104+160+64+128)+(128)+(128)+(80+80+128+128)=1496lowastn

[7] (1)+(2)+(3)+(4)+(5)+(6)=80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)+(80+64+128+160)+(128+64+80+128+160)+(128+80+128)=3728lowastn

[8] (1)+(2)+(3)+(4)+(5)= (40+80+128+24)+(80)+(40+160)+(128+128+64+160)+(128)=1160lowastn[3] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn[9] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn

[25](1)+(2)+(3)+(4)+(5)+(6)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)

+(128+80+128+128+80+128)+(160+128+128+128+128+80)+(160+128+128+128+128+80)+(128+80+128)=4592lowastn

MakingPayment

(1)+(2)+(3)+(4)+(5)+(6)+(7)=80+80+80+160+80+160+160)+(160+160+160+80)+(24+160+160)+(160+160+160)+(160+160+160+160+160+160+160+160+160)+(160+160+160)

+(48+24+40+160+160+160+160+160)=5016lowastn

Wireless Communications and Mobile Computing 9

Table 9 Computational complexity

Protocol Computational cost[1] f2 f2 SK SK f2 f1 DK f1 SK SK DK=11lowastn[5] Pub Pub Pub Pub=4lowastn[6] Pub f3 Pub SK=4lowastn[7] Pub Pub Pub Pub f2 SK f2 SK f2 SK=10lowastn[8] f3 Pub f3 Pub f2 Pub Pub SK=8lowastn[3] f2 SK SK f1 f2 f1 DK=7lowastn[9] f2 SK SK f1 f2 f1 DK=7lowastn

[25] Pub Pub Pub Pub Pub SK f2 SK f2SK=10lowastn

MakingPayment

f2 SK f3 SK f3 SK f2 SK f3 SK f3 SK SKSK SK f2 SK=17lowastn

In the case of message M3 after receiving the messagefrom the mobile operator the merchant verifies the goodsor services If these are valid a Yes message will be sent tothe mobile operator but if they are invalid a No messagewill be sent to the mobile operator and then the mobileoperator will terminate the clientrsquos request The merchantthen sends the message YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1h(Yes OI)119878119870119872119879119879119875119895 to the mobile operator The messagethat contains YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1 is for themobile operator to verify the authenticity of the merchantIt should be noted that the mobile operator does not knowthe session key SKCMj+1 that is used to construct the messageh(Yes OI SKCMj+1) since it cannot generate this message byitself This message contains h(YesNo OI SKCMj+1) in orderto guarantee information correctness and to defend againsterroneous information alteration or destructionThemessageh(Yes OI)119878119870119872119879119879119875119895 will be transmitted to TTP via the mobileoperator

In the case of message M4 upon receiving this messagefrom the merchant the mobile operator checks the creditbalance and compares it with the requested amount If theclient has enough credit the mobile operator will reply withan Accept message to the client If not the mobile operatorwill reply with a Reject message and then the client has toreturn to the Purchase Credit Request Phase The mobileoperator then sends message h(IDC IDM OI T)119878119870119862119879119879119875119895h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895 toTTP

In the case of message M5 after receiving the mes-sage from the mobile operator TTP decrypts the messageh(IDC IDM OI T)119878119870119862119879119879119875119895 with SKCTTPj h(AcceptRejectOI CLRM)119878119870119874119879119879119875119895 with SKOTTPj and h(Yes OI)119878119870119872119879119879119875119895with SKMTTPj and it keeps the decrypted message toitself Then TTP encrypts the message h(IDC IDM OIT) h(AcceptReject OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 withSKCTTPj+1 h(IDC IDM OI T) h(AcceptReject OI CLRM)h(Yes OI)119878119870119874119879119879119875119895+1 and encrypts themessage with SKOTTPj+1and h(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119872119879119879119875119895+1TTP also encrypts themessage with SKMTTPj+1and sends all the messages to the mobile operator

In the case of message M6 the mobile operator for-wards the message h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1 which is encrypted by TTPwithSKMTTPj+1 to the merchant

In the case of message M7 the mobile operator encryptsmessage one AcceptReject Yes CLRM h(Yes OI SKCMj+1)h(OI SKMOj+1)119878119870119862119874119895+1 with SK119862119874119895+1 while the messageh(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119862119879119879119875119895+1 is encrypted by TTP with SK119862119879119879119875119895+1 to theclient The message that contains AcceptReject Yes CLRMh(YesNo OI SKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 is for the clientto verify the authenticity of themobile operator It can be seenthat the mobile operator cannot deny that the message hasoriginated from himher because only the mobile operatorpossesses both SKMOj +1 and SKCOj+1 This means that themobile operator is the only one that can generate thismessage The hash value of h(YesNo OI SKCMj+1) notes thatthe mobile operator does not know the session key SK119862119872119895+1that is used to construct the message h(Yes OI SKCMj+1) andthe client to verify the authenticity of the merchant since itcannot generate this message by itself

37 Dispute Resolution Phase After the transaction is com-plete if the client is not satisfied with the transaction heshecan request a dispute resolution with the verifier The disputeresolution protocols are composed of two subprotocolsPurchase Credit Request Phase and Making Payment PhaseConsider the protocols below

371 Purchase Credit Request Theclient sends the hash valueh(IDC SN CLT 1198791) h(CLT 1198791 1198792) of the transaction to theverifier Upon receiving the hash value from the client theverifier sends the requested hash value ofTTP After receivingthe hash value fromTTP the verifier compares the hash valuefrom the client with a hash value from TTP If the hash valuesdo not match the verifier rejects the clientrsquos request if notthe verifier sends a notification of dispute resolution to themobile operator to transfer the amount to the clientrsquos accountNote that the verifier stands for the external party and is aparty that is not relevant to the particular transaction

372 Making Payment The client sends the hash valueh(IDC IDM OI T) h (OI CLRM) h(YesNo OI) of thetransaction to the verifier Upon receiving the hash valuefrom the client the verifier sends the requested hash valueof TTP After receiving the hash value from TTP the verifiercompares the hash value from the client with a hash valuefrom TTP If the hash values do not match the verifier rejectsthe clientrsquos request if not the verifier sends a notificationof dispute resolution to the mobile operator to transfer theamount to the clientrsquos account and sends notification to themerchant Note that the verifier stands for the external partyand is a party that is not relevant to the particular transaction

It is obvious that in the Purchase Credit Request Phase(Section 35) and theMaking Payment Phase (Section 36) allmessages received by the TTP are only the hash values of thetransactional data Therefore it is not possible for the TTP to

10 Wireless Communications and Mobile Computing

Table 10 Storage complexity

Protocol Storage cost[1] (1)+(2)+(3)+(4)=(80+80+160+24)+(80+160+64)+(80+24=104)+(24+80)=856lowastn[5] (1)+(2)+(3)+(4)=(160)+(64+160+80)+(64+48)+(64)=640lowastn[6] (1)+(2)+(3)= (128)+(160+80+104+160+64+128)+(80+80+128+128)=1240lowastn[7] (1)+(2)+(3)=(80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)=2400lowastn[8] (1)+(2)+(3)=(40+80+128+24)+(128+128+64+160)+(128)=880lowastn[3] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn[9] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn

[25] (1)+(2)+(3)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)+(128+80+128+128+80+128)=2752lowastn

MakingPayment (1)+(2)=(80+80+80+160+80+160+160)+(48+24+40+160+160+160+160+160)=1712lowastn

Table 11 Comparison of mobile payment protocols

Protocol Type of Fairness Uses TTP TTP Type[1] No Fairness No Without TTP[5] No Fairness No Without TTP[6] No Fairness No Without TTP[7] No Fairness No Without TTP[8] No Fairness No Without TTP[3] No Fairness No Without TTP[9] Weak Fairness Yes Online[25] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

accessmeaningful information of the transactionThismakesour protocols have strong fairness

4 Discussion

41 Security Analysis (1) Brute force attacks for the comple-tion of a transaction of our protocols the session keys changeevery time and are not reused therefore it is difficult for theattacker to find the correct session key that is shared betweenparties In addition according to [29] a brute force attackis difficult to complete by applying an offline key generationtechnique

(2) Replay attack prevention the attacker intersects themessage and resends an old message Our protocols are usedonly once with a fresh timestamp so a replay attack can beprevented and is difficult to accomplish For further detailsabout this technique the reader is referred to [29]

(3) Message integrity the integrity of the message is themost important security property that any party can ensureso that the message guarantees information correctness andis defended against erroneous information alteration ordestruction during the transmission With our protocolseach message comprises a Message Authentication Code(MAC) value that ensures the recipient of the message andthe same recent key can be used to generate a newMACThereceived MAC is compared with the calculated MAC

(4) Mutual authentication this is used to check who theoriginator and the receiver of a message are Our protocolsdeployMACs and symmetric cryptographic operations Onlythe originator and the receiver who share the same key will beable to encrypt and decrypt their messages As a result of ourprotocols eachmessage can be used to identify the originatorand the receiver so that the client the merchant and themobile operator ensure mutual authentication Consider themessage below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client and the mobile operatorshare the session key SKCOj but the mobile operator cannotgenerate thismessage by himself or herself because themobileoperator cannot generate h(OI SKCMj) as the session keySKCMj is shared only between the merchant and the clientOnly the session keys SKCMj and SKCOj are known by theclient therefore guaranteeing that the client generated thismessage

(5)Man-in-the-middle attacks an attacker cannot imper-sonate a party by intercepting message passes in theseprotocolsWith the use of limited-use session keys and propercryptographic operations no confidential information isrevealed and the reuse of authentication information islimited In addition the session keys used in our protocolsare changed constantly using strong encryption techniques

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 8: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

8 Wireless Communications and Mobile Computing

Table 5 SMS overhead of our protocols

Session SMS OverheadBytes 7-Bit ASCII (160 Byte) 8-Bit ASCII (140 Byte)

Purchase CreditM1 96 60 6875M4 88 55 6285

Making PaymentM1 126 7875 90M7 112 70 80

Table 6 Comparison of cryptographic operations

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Making PaymentSymmetric Encryption 6 - - 3 2 5 9 3 4 10Asymmetric Encryption - 4 3 4 4 - - 5 - -Message Authentication Code 3 - - 3 - - - 2 2 4Hash Function - - - - 4 2 1 - 2 3Number of Messages 9 6 5 6 6 7 9 6 4 7Number of Parties 4 4 2 5 3 3 4 5 3 4

Table 7 Comparison of energy consumption

AES (121 120583Jbyte) RSA (5465 120583Jbyte) HMAC (116 120583Jbyte) SHA1 (076 120583Jbyte) Total (120583Jbyte)[1] 726 0 348 0 1074[5] 0 2186 0 0 2186[6] 0 16395 0 0 16395[7] 363 2186 348 0 219311[8] 242 2186 0 304 219146[3] 605 0 0 152 757[9] 1089 0 0 076 1165[25] 363 27325 232 0 27385Purchase Credit 484 0 232 152 868Making Payment 121 0 464 228 1902

Table 8 Communication complexity

Protocol Communication cost (bits)

[1] (1)+(2)+(3)+(4)+(5)+(6)+(7)+(8)+(9)=(80+80+160+24)+(80+80+80+80+160+160)+(80+80+80)+(80)+(80+160+64)+(80+24)+(80+24+64+128)+(80)+(24+80)=2192lowastn

[5] (1)+(2)+(3)+(4)+(5)+(6)= (160)+(64+160+80)+(64+48)+(64)+(64)+(64)=768lowastn[6] (1)+(2)+(3)+(4)+(5)=(128)+(160+80+104+160+64+128)+(128)+(128)+(80+80+128+128)=1496lowastn

[7] (1)+(2)+(3)+(4)+(5)+(6)=80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)+(80+64+128+160)+(128+64+80+128+160)+(128+80+128)=3728lowastn

[8] (1)+(2)+(3)+(4)+(5)= (40+80+128+24)+(80)+(40+160)+(128+128+64+160)+(128)=1160lowastn[3] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn[9] (1)+(2)+(3)+(4)+(5)= (80+80+160)+(80+80)+(80)+(80+160+64)+(80)=944lowastn

[25](1)+(2)+(3)+(4)+(5)+(6)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)

+(128+80+128+128+80+128)+(160+128+128+128+128+80)+(160+128+128+128+128+80)+(128+80+128)=4592lowastn

MakingPayment

(1)+(2)+(3)+(4)+(5)+(6)+(7)=80+80+80+160+80+160+160)+(160+160+160+80)+(24+160+160)+(160+160+160)+(160+160+160+160+160+160+160+160+160)+(160+160+160)

+(48+24+40+160+160+160+160+160)=5016lowastn

Wireless Communications and Mobile Computing 9

Table 9 Computational complexity

Protocol Computational cost[1] f2 f2 SK SK f2 f1 DK f1 SK SK DK=11lowastn[5] Pub Pub Pub Pub=4lowastn[6] Pub f3 Pub SK=4lowastn[7] Pub Pub Pub Pub f2 SK f2 SK f2 SK=10lowastn[8] f3 Pub f3 Pub f2 Pub Pub SK=8lowastn[3] f2 SK SK f1 f2 f1 DK=7lowastn[9] f2 SK SK f1 f2 f1 DK=7lowastn

[25] Pub Pub Pub Pub Pub SK f2 SK f2SK=10lowastn

MakingPayment

f2 SK f3 SK f3 SK f2 SK f3 SK f3 SK SKSK SK f2 SK=17lowastn

In the case of message M3 after receiving the messagefrom the mobile operator the merchant verifies the goodsor services If these are valid a Yes message will be sent tothe mobile operator but if they are invalid a No messagewill be sent to the mobile operator and then the mobileoperator will terminate the clientrsquos request The merchantthen sends the message YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1h(Yes OI)119878119870119872119879119879119875119895 to the mobile operator The messagethat contains YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1 is for themobile operator to verify the authenticity of the merchantIt should be noted that the mobile operator does not knowthe session key SKCMj+1 that is used to construct the messageh(Yes OI SKCMj+1) since it cannot generate this message byitself This message contains h(YesNo OI SKCMj+1) in orderto guarantee information correctness and to defend againsterroneous information alteration or destructionThemessageh(Yes OI)119878119870119872119879119879119875119895 will be transmitted to TTP via the mobileoperator

In the case of message M4 upon receiving this messagefrom the merchant the mobile operator checks the creditbalance and compares it with the requested amount If theclient has enough credit the mobile operator will reply withan Accept message to the client If not the mobile operatorwill reply with a Reject message and then the client has toreturn to the Purchase Credit Request Phase The mobileoperator then sends message h(IDC IDM OI T)119878119870119862119879119879119875119895h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895 toTTP

In the case of message M5 after receiving the mes-sage from the mobile operator TTP decrypts the messageh(IDC IDM OI T)119878119870119862119879119879119875119895 with SKCTTPj h(AcceptRejectOI CLRM)119878119870119874119879119879119875119895 with SKOTTPj and h(Yes OI)119878119870119872119879119879119875119895with SKMTTPj and it keeps the decrypted message toitself Then TTP encrypts the message h(IDC IDM OIT) h(AcceptReject OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 withSKCTTPj+1 h(IDC IDM OI T) h(AcceptReject OI CLRM)h(Yes OI)119878119870119874119879119879119875119895+1 and encrypts themessage with SKOTTPj+1and h(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119872119879119879119875119895+1TTP also encrypts themessage with SKMTTPj+1and sends all the messages to the mobile operator

In the case of message M6 the mobile operator for-wards the message h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1 which is encrypted by TTPwithSKMTTPj+1 to the merchant

In the case of message M7 the mobile operator encryptsmessage one AcceptReject Yes CLRM h(Yes OI SKCMj+1)h(OI SKMOj+1)119878119870119862119874119895+1 with SK119862119874119895+1 while the messageh(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119862119879119879119875119895+1 is encrypted by TTP with SK119862119879119879119875119895+1 to theclient The message that contains AcceptReject Yes CLRMh(YesNo OI SKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 is for the clientto verify the authenticity of themobile operator It can be seenthat the mobile operator cannot deny that the message hasoriginated from himher because only the mobile operatorpossesses both SKMOj +1 and SKCOj+1 This means that themobile operator is the only one that can generate thismessage The hash value of h(YesNo OI SKCMj+1) notes thatthe mobile operator does not know the session key SK119862119872119895+1that is used to construct the message h(Yes OI SKCMj+1) andthe client to verify the authenticity of the merchant since itcannot generate this message by itself

37 Dispute Resolution Phase After the transaction is com-plete if the client is not satisfied with the transaction heshecan request a dispute resolution with the verifier The disputeresolution protocols are composed of two subprotocolsPurchase Credit Request Phase and Making Payment PhaseConsider the protocols below

371 Purchase Credit Request Theclient sends the hash valueh(IDC SN CLT 1198791) h(CLT 1198791 1198792) of the transaction to theverifier Upon receiving the hash value from the client theverifier sends the requested hash value ofTTP After receivingthe hash value fromTTP the verifier compares the hash valuefrom the client with a hash value from TTP If the hash valuesdo not match the verifier rejects the clientrsquos request if notthe verifier sends a notification of dispute resolution to themobile operator to transfer the amount to the clientrsquos accountNote that the verifier stands for the external party and is aparty that is not relevant to the particular transaction

372 Making Payment The client sends the hash valueh(IDC IDM OI T) h (OI CLRM) h(YesNo OI) of thetransaction to the verifier Upon receiving the hash valuefrom the client the verifier sends the requested hash valueof TTP After receiving the hash value from TTP the verifiercompares the hash value from the client with a hash valuefrom TTP If the hash values do not match the verifier rejectsthe clientrsquos request if not the verifier sends a notificationof dispute resolution to the mobile operator to transfer theamount to the clientrsquos account and sends notification to themerchant Note that the verifier stands for the external partyand is a party that is not relevant to the particular transaction

It is obvious that in the Purchase Credit Request Phase(Section 35) and theMaking Payment Phase (Section 36) allmessages received by the TTP are only the hash values of thetransactional data Therefore it is not possible for the TTP to

10 Wireless Communications and Mobile Computing

Table 10 Storage complexity

Protocol Storage cost[1] (1)+(2)+(3)+(4)=(80+80+160+24)+(80+160+64)+(80+24=104)+(24+80)=856lowastn[5] (1)+(2)+(3)+(4)=(160)+(64+160+80)+(64+48)+(64)=640lowastn[6] (1)+(2)+(3)= (128)+(160+80+104+160+64+128)+(80+80+128+128)=1240lowastn[7] (1)+(2)+(3)=(80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)=2400lowastn[8] (1)+(2)+(3)=(40+80+128+24)+(128+128+64+160)+(128)=880lowastn[3] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn[9] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn

[25] (1)+(2)+(3)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)+(128+80+128+128+80+128)=2752lowastn

MakingPayment (1)+(2)=(80+80+80+160+80+160+160)+(48+24+40+160+160+160+160+160)=1712lowastn

Table 11 Comparison of mobile payment protocols

Protocol Type of Fairness Uses TTP TTP Type[1] No Fairness No Without TTP[5] No Fairness No Without TTP[6] No Fairness No Without TTP[7] No Fairness No Without TTP[8] No Fairness No Without TTP[3] No Fairness No Without TTP[9] Weak Fairness Yes Online[25] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

accessmeaningful information of the transactionThismakesour protocols have strong fairness

4 Discussion

41 Security Analysis (1) Brute force attacks for the comple-tion of a transaction of our protocols the session keys changeevery time and are not reused therefore it is difficult for theattacker to find the correct session key that is shared betweenparties In addition according to [29] a brute force attackis difficult to complete by applying an offline key generationtechnique

(2) Replay attack prevention the attacker intersects themessage and resends an old message Our protocols are usedonly once with a fresh timestamp so a replay attack can beprevented and is difficult to accomplish For further detailsabout this technique the reader is referred to [29]

(3) Message integrity the integrity of the message is themost important security property that any party can ensureso that the message guarantees information correctness andis defended against erroneous information alteration ordestruction during the transmission With our protocolseach message comprises a Message Authentication Code(MAC) value that ensures the recipient of the message andthe same recent key can be used to generate a newMACThereceived MAC is compared with the calculated MAC

(4) Mutual authentication this is used to check who theoriginator and the receiver of a message are Our protocolsdeployMACs and symmetric cryptographic operations Onlythe originator and the receiver who share the same key will beable to encrypt and decrypt their messages As a result of ourprotocols eachmessage can be used to identify the originatorand the receiver so that the client the merchant and themobile operator ensure mutual authentication Consider themessage below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client and the mobile operatorshare the session key SKCOj but the mobile operator cannotgenerate thismessage by himself or herself because themobileoperator cannot generate h(OI SKCMj) as the session keySKCMj is shared only between the merchant and the clientOnly the session keys SKCMj and SKCOj are known by theclient therefore guaranteeing that the client generated thismessage

(5)Man-in-the-middle attacks an attacker cannot imper-sonate a party by intercepting message passes in theseprotocolsWith the use of limited-use session keys and propercryptographic operations no confidential information isrevealed and the reuse of authentication information islimited In addition the session keys used in our protocolsare changed constantly using strong encryption techniques

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 9: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Wireless Communications and Mobile Computing 9

Table 9 Computational complexity

Protocol Computational cost[1] f2 f2 SK SK f2 f1 DK f1 SK SK DK=11lowastn[5] Pub Pub Pub Pub=4lowastn[6] Pub f3 Pub SK=4lowastn[7] Pub Pub Pub Pub f2 SK f2 SK f2 SK=10lowastn[8] f3 Pub f3 Pub f2 Pub Pub SK=8lowastn[3] f2 SK SK f1 f2 f1 DK=7lowastn[9] f2 SK SK f1 f2 f1 DK=7lowastn

[25] Pub Pub Pub Pub Pub SK f2 SK f2SK=10lowastn

MakingPayment

f2 SK f3 SK f3 SK f2 SK f3 SK f3 SK SKSK SK f2 SK=17lowastn

In the case of message M3 after receiving the messagefrom the mobile operator the merchant verifies the goodsor services If these are valid a Yes message will be sent tothe mobile operator but if they are invalid a No messagewill be sent to the mobile operator and then the mobileoperator will terminate the clientrsquos request The merchantthen sends the message YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1h(Yes OI)119878119870119872119879119879119875119895 to the mobile operator The messagethat contains YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1 is for themobile operator to verify the authenticity of the merchantIt should be noted that the mobile operator does not knowthe session key SKCMj+1 that is used to construct the messageh(Yes OI SKCMj+1) since it cannot generate this message byitself This message contains h(YesNo OI SKCMj+1) in orderto guarantee information correctness and to defend againsterroneous information alteration or destructionThemessageh(Yes OI)119878119870119872119879119879119875119895 will be transmitted to TTP via the mobileoperator

In the case of message M4 upon receiving this messagefrom the merchant the mobile operator checks the creditbalance and compares it with the requested amount If theclient has enough credit the mobile operator will reply withan Accept message to the client If not the mobile operatorwill reply with a Reject message and then the client has toreturn to the Purchase Credit Request Phase The mobileoperator then sends message h(IDC IDM OI T)119878119870119862119879119879119875119895h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895 toTTP

In the case of message M5 after receiving the mes-sage from the mobile operator TTP decrypts the messageh(IDC IDM OI T)119878119870119862119879119879119875119895 with SKCTTPj h(AcceptRejectOI CLRM)119878119870119874119879119879119875119895 with SKOTTPj and h(Yes OI)119878119870119872119879119879119875119895with SKMTTPj and it keeps the decrypted message toitself Then TTP encrypts the message h(IDC IDM OIT) h(AcceptReject OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 withSKCTTPj+1 h(IDC IDM OI T) h(AcceptReject OI CLRM)h(Yes OI)119878119870119874119879119879119875119895+1 and encrypts themessage with SKOTTPj+1and h(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119872119879119879119875119895+1TTP also encrypts themessage with SKMTTPj+1and sends all the messages to the mobile operator

In the case of message M6 the mobile operator for-wards the message h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1 which is encrypted by TTPwithSKMTTPj+1 to the merchant

In the case of message M7 the mobile operator encryptsmessage one AcceptReject Yes CLRM h(Yes OI SKCMj+1)h(OI SKMOj+1)119878119870119862119874119895+1 with SK119862119874119895+1 while the messageh(IDC IDM OI T) h(AcceptReject OI CLRM) h(YesOI)119878119870119862119879119879119875119895+1 is encrypted by TTP with SK119862119879119879119875119895+1 to theclient The message that contains AcceptReject Yes CLRMh(YesNo OI SKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 is for the clientto verify the authenticity of themobile operator It can be seenthat the mobile operator cannot deny that the message hasoriginated from himher because only the mobile operatorpossesses both SKMOj +1 and SKCOj+1 This means that themobile operator is the only one that can generate thismessage The hash value of h(YesNo OI SKCMj+1) notes thatthe mobile operator does not know the session key SK119862119872119895+1that is used to construct the message h(Yes OI SKCMj+1) andthe client to verify the authenticity of the merchant since itcannot generate this message by itself

37 Dispute Resolution Phase After the transaction is com-plete if the client is not satisfied with the transaction heshecan request a dispute resolution with the verifier The disputeresolution protocols are composed of two subprotocolsPurchase Credit Request Phase and Making Payment PhaseConsider the protocols below

371 Purchase Credit Request Theclient sends the hash valueh(IDC SN CLT 1198791) h(CLT 1198791 1198792) of the transaction to theverifier Upon receiving the hash value from the client theverifier sends the requested hash value ofTTP After receivingthe hash value fromTTP the verifier compares the hash valuefrom the client with a hash value from TTP If the hash valuesdo not match the verifier rejects the clientrsquos request if notthe verifier sends a notification of dispute resolution to themobile operator to transfer the amount to the clientrsquos accountNote that the verifier stands for the external party and is aparty that is not relevant to the particular transaction

372 Making Payment The client sends the hash valueh(IDC IDM OI T) h (OI CLRM) h(YesNo OI) of thetransaction to the verifier Upon receiving the hash valuefrom the client the verifier sends the requested hash valueof TTP After receiving the hash value from TTP the verifiercompares the hash value from the client with a hash valuefrom TTP If the hash values do not match the verifier rejectsthe clientrsquos request if not the verifier sends a notificationof dispute resolution to the mobile operator to transfer theamount to the clientrsquos account and sends notification to themerchant Note that the verifier stands for the external partyand is a party that is not relevant to the particular transaction

It is obvious that in the Purchase Credit Request Phase(Section 35) and theMaking Payment Phase (Section 36) allmessages received by the TTP are only the hash values of thetransactional data Therefore it is not possible for the TTP to

10 Wireless Communications and Mobile Computing

Table 10 Storage complexity

Protocol Storage cost[1] (1)+(2)+(3)+(4)=(80+80+160+24)+(80+160+64)+(80+24=104)+(24+80)=856lowastn[5] (1)+(2)+(3)+(4)=(160)+(64+160+80)+(64+48)+(64)=640lowastn[6] (1)+(2)+(3)= (128)+(160+80+104+160+64+128)+(80+80+128+128)=1240lowastn[7] (1)+(2)+(3)=(80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)=2400lowastn[8] (1)+(2)+(3)=(40+80+128+24)+(128+128+64+160)+(128)=880lowastn[3] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn[9] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn

[25] (1)+(2)+(3)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)+(128+80+128+128+80+128)=2752lowastn

MakingPayment (1)+(2)=(80+80+80+160+80+160+160)+(48+24+40+160+160+160+160+160)=1712lowastn

Table 11 Comparison of mobile payment protocols

Protocol Type of Fairness Uses TTP TTP Type[1] No Fairness No Without TTP[5] No Fairness No Without TTP[6] No Fairness No Without TTP[7] No Fairness No Without TTP[8] No Fairness No Without TTP[3] No Fairness No Without TTP[9] Weak Fairness Yes Online[25] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

accessmeaningful information of the transactionThismakesour protocols have strong fairness

4 Discussion

41 Security Analysis (1) Brute force attacks for the comple-tion of a transaction of our protocols the session keys changeevery time and are not reused therefore it is difficult for theattacker to find the correct session key that is shared betweenparties In addition according to [29] a brute force attackis difficult to complete by applying an offline key generationtechnique

(2) Replay attack prevention the attacker intersects themessage and resends an old message Our protocols are usedonly once with a fresh timestamp so a replay attack can beprevented and is difficult to accomplish For further detailsabout this technique the reader is referred to [29]

(3) Message integrity the integrity of the message is themost important security property that any party can ensureso that the message guarantees information correctness andis defended against erroneous information alteration ordestruction during the transmission With our protocolseach message comprises a Message Authentication Code(MAC) value that ensures the recipient of the message andthe same recent key can be used to generate a newMACThereceived MAC is compared with the calculated MAC

(4) Mutual authentication this is used to check who theoriginator and the receiver of a message are Our protocolsdeployMACs and symmetric cryptographic operations Onlythe originator and the receiver who share the same key will beable to encrypt and decrypt their messages As a result of ourprotocols eachmessage can be used to identify the originatorand the receiver so that the client the merchant and themobile operator ensure mutual authentication Consider themessage below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client and the mobile operatorshare the session key SKCOj but the mobile operator cannotgenerate thismessage by himself or herself because themobileoperator cannot generate h(OI SKCMj) as the session keySKCMj is shared only between the merchant and the clientOnly the session keys SKCMj and SKCOj are known by theclient therefore guaranteeing that the client generated thismessage

(5)Man-in-the-middle attacks an attacker cannot imper-sonate a party by intercepting message passes in theseprotocolsWith the use of limited-use session keys and propercryptographic operations no confidential information isrevealed and the reuse of authentication information islimited In addition the session keys used in our protocolsare changed constantly using strong encryption techniques

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 10: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

10 Wireless Communications and Mobile Computing

Table 10 Storage complexity

Protocol Storage cost[1] (1)+(2)+(3)+(4)=(80+80+160+24)+(80+160+64)+(80+24=104)+(24+80)=856lowastn[5] (1)+(2)+(3)+(4)=(160)+(64+160+80)+(64+48)+(64)=640lowastn[6] (1)+(2)+(3)= (128)+(160+80+104+160+64+128)+(80+80+128+128)=1240lowastn[7] (1)+(2)+(3)=(80+128+80+128+80+128+80+128)+(128+128+128+80+128+128+128+80)+(80+64+128+128+80+160)=2400lowastn[8] (1)+(2)+(3)=(40+80+128+24)+(128+128+64+160)+(128)=880lowastn[3] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn[9] (1)+(2)+(3)=(80+80+160)+(80+160+64)+(80)=704lowastn

[25] (1)+(2)+(3)=(80+128+128+80+80+128+128+80)+(128+128+128+80+80+80+128+128+128+80+80+80)+(128+80+128+128+80+128)=2752lowastn

MakingPayment (1)+(2)=(80+80+80+160+80+160+160)+(48+24+40+160+160+160+160+160)=1712lowastn

Table 11 Comparison of mobile payment protocols

Protocol Type of Fairness Uses TTP TTP Type[1] No Fairness No Without TTP[5] No Fairness No Without TTP[6] No Fairness No Without TTP[7] No Fairness No Without TTP[8] No Fairness No Without TTP[3] No Fairness No Without TTP[9] Weak Fairness Yes Online[25] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

accessmeaningful information of the transactionThismakesour protocols have strong fairness

4 Discussion

41 Security Analysis (1) Brute force attacks for the comple-tion of a transaction of our protocols the session keys changeevery time and are not reused therefore it is difficult for theattacker to find the correct session key that is shared betweenparties In addition according to [29] a brute force attackis difficult to complete by applying an offline key generationtechnique

(2) Replay attack prevention the attacker intersects themessage and resends an old message Our protocols are usedonly once with a fresh timestamp so a replay attack can beprevented and is difficult to accomplish For further detailsabout this technique the reader is referred to [29]

(3) Message integrity the integrity of the message is themost important security property that any party can ensureso that the message guarantees information correctness andis defended against erroneous information alteration ordestruction during the transmission With our protocolseach message comprises a Message Authentication Code(MAC) value that ensures the recipient of the message andthe same recent key can be used to generate a newMACThereceived MAC is compared with the calculated MAC

(4) Mutual authentication this is used to check who theoriginator and the receiver of a message are Our protocolsdeployMACs and symmetric cryptographic operations Onlythe originator and the receiver who share the same key will beable to encrypt and decrypt their messages As a result of ourprotocols eachmessage can be used to identify the originatorand the receiver so that the client the merchant and themobile operator ensure mutual authentication Consider themessage below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client and the mobile operatorshare the session key SKCOj but the mobile operator cannotgenerate thismessage by himself or herself because themobileoperator cannot generate h(OI SKCMj) as the session keySKCMj is shared only between the merchant and the clientOnly the session keys SKCMj and SKCOj are known by theclient therefore guaranteeing that the client generated thismessage

(5)Man-in-the-middle attacks an attacker cannot imper-sonate a party by intercepting message passes in theseprotocolsWith the use of limited-use session keys and propercryptographic operations no confidential information isrevealed and the reuse of authentication information islimited In addition the session keys used in our protocolsare changed constantly using strong encryption techniques

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 11: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Wireless Communications and Mobile Computing 11

Table 12 Comparison of fair exchange protocols

Protocol Type of Fairness Use TTP TTP Type[13] Weak Yes Inline[26] Weak Yes Online[15] Weak Yes Online[21] Weak Yes Offline[23] Weak Yes Offline[24] Weak Yes Offline[17] Weak Yes Online[11] No Fairness No Without TTPPurchase Credit Strong Yes OnlineMaking Payment Strong Yes Online

Table 13 Comparison security properties

[1] [5] [6] [7] [8] [3] [9] [25] Purchase Credit Request Making PaymentConfidentiality Y Y Y Y Y Y Y Y Y YIntegrity Y N N Y Y Y Y Y Y YMutual authentication Y N N Y Y Y N Y Y YNon-repudiation N Y N Y Y N N Y Y YBrute force attack N Y Y N Y N Y N Y YReplay attack prevention Y N Y Y Y Y Y Y Y YMan-in-the-middle attack Y Y Y Y Y Y Y Y Y YMS disclosure Y Y Y Y Y Y Y Y Y YOver the air modification Y Y Y Y Y Y Y Y Y YImpersonation attack Y Y N Y Y Y N Y Y YSMS spoofing Y Y Y Y Y Y Y Y Y Y

Table 14 Notations of BAN logic [27]

Notation DefinitionsX Y StatementP Q PartiesP| equivX P believes in XP⊲X P sees XP| simX P once said XP| 997904rArrX P has the jurisdiction over X(X) The formula X is freshP 119883larrrarr Q P and Qmay use the shared key K to communicateP119883

lArrrArr Q The formula Y is a secret known only to P and Q119883119870 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 tobe analyzed by an attacker who fraudulently feigns a party

(6) Nonrepudiation of transactions ordinarily anencrypted message with the private key of a public keyencryption operation provides a nonrepudiation propertya party cannot decline the transactions he or she hasperformedHowever an encryptedmessagewith a symmetrickey of symmetric key encryption operations cannot providea nonrepudiation property Nevertheless nonrepudiation

properties can be satisfied by encrypting messages with asymmetric key encryption Being able to collect evidencefrom each message our protocols demonstrate the actionsthat all parties have performed in each transaction To seethe nonrepudiation properties of our proposed protocolssee the message below

M1 C 997888rarr O IDC T IDM OI T h(OI SKCMj)119878119870119862119874119895h(IDC IDM OI T)119878119870119862119879119879119875119895

It can be seen that the client cannot decline that themessage heshe generated originated from himher This isbecause only the client possesses both SKCMj and SKCOj Thisindicates that only the client can generate this message

(7) Confidentiality generally symmetric key encryptionoperations provide confidentiality of the security propertiesof the messages Every message of our protocols applies sym-metric key encryption operations to lead the confidentialityof the messages The same session keys shared between thesender and receiver will be able to encrypt and decrypt theirmessages

(8) SMS disclosure at present the confidentiality andintegrity of the message do not provide the transmissionof the SMS message Our protocols use symmetric keyencryption and hash functions to satisfy confidentiality andintegrity from SMS disclosure of all the messages

(9) Over-the-airmodification although the global systemfor a mobile communication network uses cryptographic

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 12: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

12 Wireless Communications and Mobile Computing

Figure 2 SPDL script of Purchase Credit Request Phase

techniques of A51 and A52 between the mobile device andthe base station subsystem they are still vulnerable [1ndash4] Ourprotocols provide end-to-end security from the sender to thereceiver by a strong encryption algorithm (such as AES)

(10) Impersonation attack an attacker who impersonatesa party cannot complete the attack because each message inour protocols provides mutual authentication of all parties ofthe transactionsMoreover eachmessage can be used to iden-tify the sender and the receiver who share the same sessionkeys Our protocols can prevent impersonation attacks

(11) SMS spoofing an attacker can spoof the client bysending an SMS message with the correct headers via theInternet Our protocols utilize a secure session key generationtechnique in that only the sender and the receiver whoshare the same key will be able to encrypt and decrypt theirmessages Moreover our protocols on all parties providemutual authentication It can be seen that our protocolsprevent SMS spoofing attacks

42 Formal Security Verification of Our Protocols TheScyther tool is used to verify the robustness and soundnessof our protocols The Scyther tool is a formal proofreaderfor security protocols It is an automated security proto-col analysis tool based on Security Protocol DescriptionLanguage (SPDL) Scyther [36 37] SPDL provides threemain protocol modelling features roles events and claimsA lot of researchers have now utilized the Scyther tool tovalidate security protocols see [25 38ndash41] The followingsecurity claims are verified in the analysis secrecy of data(Secret) aliveness (Alive) weak agreement (Weakagree)noninjective agreement (Niagree) and noninjective synchro-nization (Nisynch) [37] Our protocols are verified using theldquoVerification Claimrdquo scheme in the Scyther tool

Figures 2 and 3 display the SPDL script for verifying ourprotocol Figures 4 and 5 show the output of the tests of ourproposed protocols Most of the claims are utilized to verify

Figure 3 SPDL script of Making Payment Phase

Figure 4 Output of Purchase Credit Request Phase

the security properties with a status (OK) for all the claimsand no attacks are discovered within bounds

43 Performance Analysis of the Proposed Protocols Ourperformance analysis follows the analysis of the mobilepayment protocols [1 3 5ndash9 25] and the fair exchangeprotocols [11 13 15 17 21 24 26] by focusing on severalaspects related to the transaction performance eg thenumber of cryptographic operations applied to each protocoland the number of messages passed in each protocol Wethen show that our protocols have a greater performance thanother existing SMS payment and fair exchange protocolsOur protocols utilize the symmetric encryption AdvancedEncryption Standard (AES) 128 bits

Tables 2 and 3 show symbols and abbreviations andcryptographic operation functions for use in this part of thepaper in order to complete performance analysis

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 13: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Wireless Communications and Mobile Computing 13

Figure 5 Output of Making Payment Phase

Table 4 illustrates the message length of our protocolswhich are considered as a lightweight cryptographic opera-tion Moreover the message length of our protocols is lessthan the maximum message length of an SMS (160 bytes) inmessages M1 and M4 (Purchase Credit Request Phase) andin messages M1 and M7 (Making Payment) Our protocolscan be implemented in the current SMS infrastructure andtherefore maintain ease of use

Table 5 shows the SMS overhead of our protocols TheSMS overhead is calculated only with transactions betweenthe client and the mobile operator The client sends M1(Purchase Credit Request Phase) to the mobile operatorThe mobile operator sends M4 (Purchase Credit RequestPhase) 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 ourprotocols generate a minimum SMS overhead Besides theSMSoverhead of our protocols is less than themaximumSMSoverhead of an SMS (160 bytes)

Table 6 demonstrates the comparison of the crypto-graphic operations of our protocols with the proposed pro-tocols in [1 3 5ndash9 25] Our protocols utilize different cryp-tography techniques such as a hash function and symmetricencryption It can be inferred that our protocols use theminimum cryptographic operation

The energy consumption of our protocols accordingto [42] presents a framework for the energy consumptionanalysis of security protocols and cryptographic algorithmssuch as asymmetric symmetric hash function and MessageAuthenticationCode (MAC) algorithms Anumber of frame-works have been proposed [43ndash45]

Table 7 shows the energy cost comparison of our proto-cols with other protocols [1 3 5ndash9 25] It can be seen that ourprotocols use a lower energy cost than the protocols proposedin [5ndash9 25]The protocols in [1 3 9] use less energy than our

0

1000000

2000000

3000000

4000000

5000000

6000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 6 Communication overhead

02000400060008000

1000012000140001600018000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 7 Computation overhead

protocols However our protocols have a smaller number ofmessages than the protocols proposed in [1 3 9] so they takeless time to accomplish every correlated transaction [1 3 9]

Table 8 and Figure 6 demonstrate comparisons of com-munication cost between the proposed protocols and existingprotocols in [1 3 5ndash9 25] It can be seen that the proposedprotocols has a higher communication cost than the protocolsproposed in [1 3 5ndash9 25] Nevertheless the SMSmobile pay-ment protocols in [1 3 5ndash9 25] are weak in terms of fairnessaccording to themodel described in Section 32 Moreover inthe case that one partymisbehaves the protocols proposed in[1 3 5ndash9 25] cannot resolve any dispute because they do notprovide the dispute resolution phase Note that n is numberof transactions

From Table 9 and Figure 7 the protocols proposed in [13 5ndash9 25] have lower computational cost than our protocols

Table 10 and Figure 8 compare the storage costs of theprotocols found in [1 3 5ndash9 25] with the one of our protocolsIt is clear that our protocols have a higher storage cost than

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 14: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

14 Wireless Communications and Mobile Computing

0

500000

1000000

1500000

2000000

2500000

3000000

Num

ber o

f bits

400 600 800 1000200Number of transactions

[1][5][6][7][8]

[3][9][25]Making Payment

Figure 8 Storage overhead

the protocols proposed in [1 3 5 6 8 9] but lower than theones in [7 25]

Table 11 illustrates a fairness comparison between ourproposed protocols and existing mobile payment protocols[1 3 5ndash8 25] As can be seen in Table 11 protocols proposedin [1 3 5ndash8 25] have no trusted third party involved Hencethose protocols do not have fairness according to the modelpresented in Section 32 Minta and Panchami [9] proposedan efficient encryption protocol for secure transmission ofa confidential SMS The Certification Authority and Reg-istration Authority (CARA) are a trusted third party Itcan read important information because CARA maintainsa database containing the certificates of PK-SIM cards andSecure Access Gateway (SAGs) and Certificate RevocationLists (CRLs) Thus this protocol is weak in terms of fairnessIn contrast our proposed protocols satisfy the strong fairnessas described Section 32

Table 12 illustrates the comparison of the fairness aspectof different protocols Mohammed [13] presented a trans-fer protocol ownership The transaction server can readimportant information a contract to be signed by both thebuyer and the seller by the private key of the transactionserver the results of verification buyers account numbersellers account number and amount Hence Mohammedrsquosprotocol is weak in terms of fairness according to themodel described in Section 32 Chen [26] proposed a fairtransaction model in mobile commerce which is based ona personal trusted device The customer of the businesscan read a considerable amount of information the detailsof their purchases the delivery address (which may be anemail address or a physical address) dates billing addressesshipping addresses the customerrsquos own account and the totalprice Thus Chenrsquos protocol is also weak in terms of fairnessAlotaibi [15] proposed a new fair exchange protocol fortrading goods online The financial service provider can readall significant information digital goods and invoices thatare encrypted with temporary session keys of the financialservice provider in the pre-exchange phase the name of the

financial institution of the customer personal informationabout the customer account details of the customer andthe total amount of money that the customer will pay forthe digital goods These are encrypted with the private keyof the customer in the exchange phase Therefore Alotaibirsquosprotocol is weak in terms of fairness Mohammed [21]proposed fair exchange protocols between a customer anda merchant The trusted third party can read importantinformation payments that are encrypted with the privatekey of the customer and digital goods that are encryptedwith the session key of the merchant that is encryptedwith the public key of the trusted third party ThereforeMohammedrsquos protocol is alsoweak in terms of fairness Alaraj[23] proposed a fair certified email protocolThe trusted thirdparty can read a considerable amount of information themailthat is encryptedwith its senderrsquos session key that is encryptedwith the public key shared between the sender and the trustedthird party The trusted third party can decrypt messageswith the private key shared between the trusted third partyand the sender in the recovery subprotocol Hence Alarajrsquosprotocol is weak in terms of fairness Hinarejos [24] proposedan efficient and provable fair document exchange protocolThe trusted third party can read a considerable amount ofinformation such as parameters which generate a sessionkey to encrypt the document of party A and party B ThusHinarejosrsquos protocol is weak in terms of fairness Liu [17]proposed a nonrepudiation protocol which is based on areceiver-side smart card The trusted third party can readsignificant information a message to be exchanged betweenthe customer and the vender This message is encryptedwith a session key generated by the trusted third partyTherefore Liursquos protocol is weak in terms of fairness Paulin[11] proposed a fair nonrepudiation certified email protocolThis protocol either does or does not involve the trusted thirdparty as the mediator between the senders and the receiversIn this way Paulinrsquos protocol has no fairness Our protocolssatisfy strong fairness according to the model presented inSection 32

Table 13 shows a comparison of the security properties ofthe protocols found in the literature [1 3 5ndash7 9 25] and ourprotocols It is clear that our protocols and [8] satisfy the nec-essary security properties which are confidentiality integritymutual authentication nonrepudiation brute force attackreplay attack prevention man-in-the-middle attack and SMSdisclosure over-the-air modification impersonation attackand SMS spoofing Note that Y and N mean ldquosatisfyingrdquo andldquounsatisfyingrdquo

5 Analysis of Fairness

In this section we analyze our proposed protocols in termsof the fairness properties of the Purchase Credit RequestPhase and the Making Payment Phase We also provide someguidelines to prove the fairness of our proposed protocolsIt can be seen that to complete a transaction in the clientrsquosopinion the payment-order response from the mobile oper-ator must contain the amount requested by the client andthe debit response from themobile operator must contain theamount where the client has requested the mobile operator

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 15: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Wireless Communications and Mobile Computing 15

to deduct from hisher account In other words the clientnot only has to receive payment responses but also has toreceive payment-order and debit from the mobile operator(on behalf of the mobile operator) respectively All requestsare sent to the trusted third party According to the modelstated in Section 32 our protocols then satisfy the fairnessproperties for all parties the clients the mobile operator andthe merchant

Our analysis of fairness is derived from [46] The readermay find more details about Kungpisdanrsquos logic from [46]

51 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) 120593 a set of statements derived from messages

(iv) 119870997888rarr Q key K can be used to refer to Q

(v) P 119870larrrarr Q key 119870 is the shared key between 119875 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 toa 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 119883 from a single-key cryptographicmessage

52 Formulae

(i) P believes 120593 P believes that the statement 120593 is true(ii) P sees X Some party has sent a message119883 to 119875 and 119875

is able to read X(iii) P has X P possesses a message X P can send 119883 to

other parties or use it for further computations(iv) P says X P has sent message X(v) P CanProve 120593 to Q P can prove to 119876 that statement 120593

is true(vi) P authorized payment (P Q OI datetime) P has

authorization to make the payment amount Price to119876 on datetime the datetime of transaction

(vii) P authorized debit (P Q OI datetime) P has autho-rization to request119876 to deduct the amount Price fromPrsquos account on datetime the datetime of transaction

(viii) P authorized credit (P Q OI datetime) P has autho-rization to request 119876 to transfer the amount Price toPrsquos account on datetime the datetime of transaction

53 Axioms

531 Comprehensions C1 P sees X 997888rarr P believes P sees X

532 Inference Rules M If120593 is a theorem then119875believes120593 isa theorem where theorem is a formula which can be derivedfrom axioms alone

533 Possessions H1 P sees X 997888rarr P has XH2 (P has 1198831 ⋀ ⋀ P has 119883119899)larrrarr P has (1198831 119883119899)

where (1198831 119883119899) stands for a list of messages 1198831 1198832 119883119899 respectively

H3 P has X 997888rarr P has h(X)H4 (P has (119883119870 K)⋀ P believes P 119870larrrarr Q) 997888rarr P has X

534 Provability P2 [V-is-external-party ⋀ P has X ⋀ (Vsees X 997888rarr V believes 120593)] 997888rarr P CanProve 120593 to V

P3rsquo If 119875 has M X119870 and a key Krsquo P believes that Krsquo isshared between119876 and a party Prsquo P can prove to119881 that Krsquo canbe used to decrypt M X119870 and 119875 can also prove to119881 that119883is shared between 119876 and R and then 119875 can prove to 119881 that 119876has sent119883 to Prsquo

[P has (M X119870 Krsquo) ⋀ P believes Prsquo 119870larrrarr Q ⋀ P CanProve(1198701015840-is-decrypting-key-for-119872119883119870) to V

⋀ P CanProve (Q 119883larrrarr R) to V]997888rarr P CanProve (Q says (M X IDPrsquo)) to VP6 P CanProve (Q says (1198831 119883119899)) to Vlarrrarr [P CanProve (Q says1198831) to V⋀ ⋀ P CanProve (Q

says119883119899) to V]

54 Initial Assumptions The following assumptions are spe-cific to our fairness protocols

541 General Assumptions A1 Every party believes that if119881believes thatKrsquo is shared between parties119876 and RV has both⟨X⟩K andKrsquo andKrsquo can be used to extract119883 from ⟨X⟩Krsquo then119881 believes that ⟨X⟩K is shared between 119876 and R

P believes [(V believes Q 1198701015840

larrrarr R ⋀ V has (⟨X⟩K Krsquo) ⋀ X =⟨⟨X⟩K⟩Krsquo) 997888rarr V believes Q

⟨119883⟩119870larr997888997888rarr R]

Here119876 and 119877 stand for any two participants assumptionA1 together with axiom P2 is used for reason that if119881 believesthat 119870 is a secret shared between two parties then anymessage that is applied with the single-key operation relevantto 119870must be considered a shared secret as well

A2Every party believes that if119881 believes that heshe doesnot generate ⟨X⟩K by himselfherself Krsquo is shared between Prsquoand Q V has both ⟨X⟩K and Krsquo and Krsquo can be used to extract119883 from ⟨X⟩Krsquo then 119881 believes that 119876 has sent119883 to party Prsquo

P believes (V believes Prsquo sees ⟨X⟩K ⋀ V believes Prsquo 1198701015840

larrrarr Q⋀ V has (⟨X⟩Krsquo Krsquo) ⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believes Q says (XIDP1015840 ))

A3 Every party believes that if 119881 has messages 119883 and119884 and message 119883 is h(Y) then 119881 believes that 119883 is thefingerprint of Y

P believes [(V has (X Y)⋀ X = h(Y) ) 997888rarr V believes X-is-fingerprint-of-Y]

A4 Every party believes that if 119881 has key Krsquo and thesingle-key cryptographic message ⟨X⟩K and Krsquo can be used

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 16: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

16 Wireless Communications and Mobile Computing

to derive ⟨X⟩K then V believes that Krsquo is the deriving key for⟨X⟩K

P believes (V has ⟨X⟩K Krsquo)⋀ X = ⟨⟨X⟩K⟩Krsquo 997888rarr V believesKrsquo-is-deriving-key-for-⟨X⟩K)

542 Possessions A5 Each player has their own identities119875 believes 119875 has 119868119863119875 C believes C has 119868119863119872M believes M has 119868119863119862 O believes O has 119868119863119872O believes O has IDC

543 Shared Secrets A6Theclient and themerchant believethat SKCM and 119873119878119870119862119872 are shared between them and theyalso have SKCM The client and the mobile operator believethat SKCO and 119873119878119870119862119874 are shared between them and theyalso have SKCO The merchant and the mobile operatorbelieve that SKMO and 119873119878119870119872119861 are shared between them andthey also have SKMO

P believes C119878119870119862119872larr997888997888997888rarrM P believes C

119873119878119870119862119872larr997888997888997888997888997888rarrM P believes P

has SKCM where 119875 denotes 119862 and M and119873 is a message

Q believes C119878119870119862119874larr997888997888rarrO P believes C

119873119878119870119862119874larr997888997888997888997888rarrO Q believes Q

has SKCO where Q denotes C and OR believesM

119878119870119872119874larr997888997888997888rarrOR believesM

119878119870119872119874larr997888997888997888rarrOR believes R has

SKMO where 119877 denotes119872 and OA7 Each player believes that the merchant does not

receive SKCO themobile operator does not receive SKCM andthe client does not receive SKMO

119875 believes notM sees 119878119870119862119874 119875 believes not O sees 119878119870119862119872P believes not C sees SKMO

544 Verifierrsquos Beliefs A8 Each player believes that theverifier is an external party to whom every participant is ableto reveal its secrets

P believes V-is-external-partyQ believes V believes C

119878119870119862119872larr997888997888997888rarrM Q believes V believes

C119873119878119870119862119872larr997888997888997888997888997888rarrM Q believes V believes C

119878119870119862119874larr997888997888rarrO

Q believes V believes C119873119878119870119862119874larr997888997888997888997888rarrO Q believes V believes

M119878119870119872119874larr997888997888997888rarrO Q believes V believes M

119873119878119870119872119874larr997888997888997888997888997888rarrO

Q believes notV believes C1198721larr997888rarrO Q believes notV believes

C1198722larr997888rarrO Q believes notV believes M

1198723larr997888rarrO

Here 119876 denotes any participant N denotes a messageor a message component 1198721 denotes the message that isdifferent from SKCM and 1198731198781198701198621198721198722 denotes the messagethat is different from SKCO and 119873119878119870119862119874 and1198723 denotes themessage that is different from SKMO and 119873119878119870119872119874

545 Payment Information A9 The client and themerchantbelieve that they possess the price and statement

Q believes Q has (OI) where 119876 denotes 119862 and 119872 Notethat the merchant hasOI because heshe has the informationabout goods or services such as the description and price

546 PaymentAuthorizations A10Each player believes thatheshe can prove to the verifier that if the client has sent themessage containing IDM identity price and the datetime of

transaction the client has authorization to order goods orservices from the merchant

P believes P CanProve (C says (IDM OI datetime)997888rarr C authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing IDCprice and the datetime of the transaction the merchant hasauthorization to issue the payment receipt to the client

P believes P CanProve (M says (IDC OI datetime)997888rarrM authorized payment-order(C M OI datetime)) to

VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDC OI and the datetime of transaction the mobile operatorhas authorization to debit from the clientrsquos account

P believes P CanProve (O says (IDC OI datetime)997888rarr O authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the client has sent the message containing OI and thedatetime of the transaction then the client has authorizationto request the mobile operator to deduct the requestedamount from hisher account

P believes P CanProve (C says (OI datetime)997888rarr C authorized debit(C O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the mobile operator has sent the message containingIDM OI and the datetime of the transaction then the mobileoperator has authorization to transfer the requested amountto the account of the merchant

P believes P CanProve (O says (IDM OI date)997888rarr O authorized credit(M O OI datetime)) to VEach player believes that heshe can prove to the verifier

that if the merchant has sent the message containing OIand the datetime of the transaction then the merchant hasauthorization to request the mobile operator to transfer therequested amount to the merchant account

P believes P CanProve (M says (OI datetime)997888rarrM authorized credit(M O OI datetime)) to V

55TheGoals of Analysis To evaluate the fairness we specifythe goals regarding the fundamental interactions betweenpairs of engaging parties the payment-order between theclient and the merchant the debiting between the clientand the mobile operator and the crediting between themerchant and the mobile operator We state the goals G1-G6by associating them with the abilities to prove the primitiveinteractions stated in Section 32 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 OIdatetime)) to V

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

G5 O believes O CanProve (M authorized credit(M O OIdatetime)) to V

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 17: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Wireless Communications and Mobile Computing 17

G6MbelievesMCanProve (O authorized credit(OMOIdatetime)) to V

56 Details of the Proof Due to the limited space we are notable to describe all details of our fairness analysis Howeverwe can provide some guidelines to prove G4 of the PurchaseCredit Request Phase and G1 of the Making Payment Phaseas follows

G4 C believes C CanProve (O authorized debit(O C OIdatetime)) to V

Consider message 4 of Purchase Credit Request PhaseM4 O 997888rarr C 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN

CLT 1198791) h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1It can be transformed intoC sees 1198792 h(CLT 1198791 1198792 SKCOj+1) h(IDC SN CLT 1198791)

h(CLT 1198791 1198792)119878119870119862119879119879119875119895+1Detail of the proof can be shown as follows

C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (1)1 C1 M C believes C sees T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (2)2 H1 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) h(IDC SN CLT T1) h(CLT T1 T2)119878119870119862119879119879119875119895+1 (3)3 A6 H2 M C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 (4)A7 4 A2 P2 M C believes V-is-external-party⋀ (5)C believes C has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀

C believes (V believes (C119878119870119862119874119895+1larr997888997888997888997888rarrO)⋀

V believes C sees h(CLT T1 T2 SKCOj+1)⋀V has T2 h(CLT T1 T2 SKCOj+1) CLT T1 SKCOj+1 ⋀h(CLT T1 T2 SKCOj+1) = h(CLT T1 T2 SKCOj+1)997888rarr V believes O says (CLT T1 T2)997888rarr C believes C CanProve (O says CLT T1 T2) to V5 P6 M C believes C CanProve (O says CLT T1 T2) to V (6)

The goal G4 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G1ndashG3 andG5ndashG6 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 PhaseM2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895It can be transformed intoM sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895Detail of the proof can be shown as follows

M sees OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (1)1 C1 H1 H2 M M believes M has OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895 (2)2 A6 H2 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895) (3)A7 3 A5 P2 M M believes M CanProve (SKMOj-is-decrypting-key-for-OI h(OI SKCMj) h(OISKCOj+1) T119878119870119872119874119895) to V

(4)

3 A6 H4 M M believes M has (OI h(OI SKCMj) h(OI SKCOj+1) T) (5)5 H2 M M believes M has h(OI SKCMj) (6)4 H3 M M believes M has (h(OI)) (7)7 A5 H2 M M believes M has (h(OI) SKCMj) (8)

A7 6 8 H2 A1 P2 M M believes M CanProve (Cℎ(119874119868119878119870119862119872119895)

larr997888997888997888997888997888997888997888997888rarrM) to V (9)

3 A6 4 9 P3 M M believes M CanProve (C says (OI h(OI SKCMj) T)) to V (10)10 P6 M M believes M CanProve (C says (OI T)) to V (11)11 A9 M M believes M CanProve (C authorized payment-order(C M OI)) to V (12)

The goal G1 is successfully proved Thus it can beconcluded that the merchant is satisfied with the fairnessNote that the details of the analysis of goals G2ndashG6 weresuccessfully analyzed

6 Security Proof Based on BAN Logic

We use BAN logic model to prove the mutual authenticationof our protocols The BAN logic [27] is a well-knownformal model which is used to examine the security ofmutual authenticationThe literature in [47] has now utilized

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 18: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

18 Wireless Communications and Mobile Computing

the BAN logic to verify the security of mutual authenti-cation The notations used in BAN logic are defined inTable 14

Moreover the proposed protocols use six rules of BANlogic to prove a secure mutual authentication betweenparties

R1 Message-meaning rule 119875| equiv 119875119870larrrarr 119876119875 ⊲ 119883119870119875| equiv

119876| sim 119883 119875| equiv 119875 119870larrrarr 119876119875 ⊲ (119883)119870119875| equiv 119876| sim 119883R2 Nonce-verification rule119875| equiv (119883) 119875| equiv 119876| sim 119883119875| equiv

119876| equiv 119883R3 Jurisdiction rule 119875| equiv 119876 997904rArr 119883119875| equiv 119876| equiv 119883119875| equiv 119883R4 Freshness rule 119875| equiv (119883)119875| equiv (119883 119884)R5 Belief rule 119875| equiv (119883) 119875| equiv 119884119875| equiv (119883 119884)

R6 Decryption rules 119875| equiv 119876 119870larrrarr 119875119875 ⊲ 119883119870119875 ⊲ 119883We analyze both Purchase Credit Request and Making

Payment Phases in order to complete a secure mutualauthentication of all parties Our protocols are listed asfollows

61 Purchase Credit Request Phase

611 Idealized Form

M1 C997888rarrO (SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

M4 O997888rarr C (CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

612 Initial Assumptions

A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 C| equiv C

119878119870119862119874119895+1larr997888997888997888997888rarrO

A3 O| equiv (1198791) A4 C| equiv (1198792)

613 The Goals of Analysis G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr

119874) G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

614 Details of the Proof G1 O| equiv(SN CLT 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874)

O⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) from message M1 1

1 R1 O| equivO⊲(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 2

2 R2 R4 A1 A3 O| equivO has (1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 3

3 R5 O| equivO has (SN CL119879) 4

4 O| equiv(SN CL119879 1198791 C119878119870119862119874119895larr997888997888997888rarr 119874) 5

G2 C| equiv(CLT 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

C⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) from message M4 1

1 R1 C| equivC⊲(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 2

2 R2 A2 C| equivC has (CL119879 1198791 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 3

3 R4 R5 A4 C| equivC has (1198792) 4

4 O| equiv(CL119879 1198791 1198792 C119878119870119862119874119895+1larr997888997888997888997888rarr 119874) 5

The goals are successfully proved in Purchase CreditRequest Phase Thus it can be concluded that all parties havesatisfied a secure mutual authentication

62 Making Payment Phase M1 C 997888rarrO IDC T IDM OIT h(OI SKCMj)119878119870119862119874119895 h(IDC IDM OI T)119878119870119862119879119879119875119895

M2 O997888rarrM OI h(OI SKCMj) h(OI SKCOj+1) T119878119870119872119874119895M3 M 997888rarr O YesNo h(Yes OI SKCMj+1)119878119870119872119874119895+1

h(Yes OI)119878119870119872119879119879119875119895M4 O 997888rarr TTP h(IDC IDM OI T)119878119870119862119879119879119875119895

h(AcceptReject OI CLRM)119878119870119874119879119879119875119895 h(Yes OI)119878119870119872119879119879119875119895M5 TTP 997888rarr O h(IDC IDM OI T) h(AcceptReject

OI CLRM) h(Yes OI)119878119870119862119879119879119875119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes OI)119878119870119874119879119879119875119895+1 h(IDCIDM OI T) h(AcceptReject OI CLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M6 O 997888rarr M h(IDC IDM OI T) h(AcceptReject OICLRM) h(Yes OI)119878119870119872119879119879119875119895+1

M7 O 997888rarr C AcceptReject Yes CLRM h(Yes OISKCMj+1) h(OI SKMOj+1)119878119870119862119874119895+1 h(IDC IDM OI T)h(AcceptReject OI CLRM) h(Yes IO)119878119870119862119879119879119875119895+1

621 Idealized Form M1 C 997888rarr O119868119863119872119874119868 119879 (119874119868 119862

119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr 119874

M2 O997888rarrM OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874

M3 M 997888rarr O YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

M7 O 997888rarr C AcceptReject Yes CLRM (Yes OI

119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 19: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Wireless Communications and Mobile Computing 19

622 Initial Assumptions A1 O| equiv 119862119878119870119862119874119895larr997888997888997888rarrO A2 M| equiv

119862119878119870119862119872119895larr997888997888997888rarrM

A3M| equiv 119862119878119870119872119874119895larr997888997888997888rarrO A4 O| equiv 119862

119878119870119872119874119895+1larr997888997888997888997888997888rarrO

A5 C| equiv 119862119878119870119862119874119895+1larr997888997888997888997888rarrO A6 C| equiv 119862

119878119870119862119872119895+1larr997888997888997888997888rarrM

A7 O| equiv (T)

623 The Goals of Analysis G1 O| equivIDM OI T (OI

119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarrO G2M| equiv(OI 119862

119878119870119862119872119895larr997888997888997888rarr 119872)

G3 M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874)

T119872119878119870119872119874119895larr997888997888997888rarr 119874 G4 O| equivYesNo (Yes OI 119862

119878119870119862119872119895+1larr997888997888997888997888rarr

119872)119872119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) G6 C| equivAcceptReject

Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI 119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr

119874)119862119878119870119862119874119895+1larr997888997888997888997888rarr 119874

624 Details of the Proof G1O| equivIDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr

119872)119862119878119870119862119874119895larr997888997888997888rarrO

O⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O from message M1 1

1 R1 O| equivO⊲ IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 2

2 R6 A1 O| equivO has IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 3

3 R4 A7 O| equivO⊲(IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)) 4

4 O| equiv IDM OI T (OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)119862

119878119870119862119874119895larr997888997888997888rarr O 5

G2M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872)

M⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) from message M1 1

1 R1 M| equivM⊲(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 2

2 A2 M| equivM has (119862119878119870119862119872119895larr997888997888997888rarr 119872) 3

3 R5 M| equivM has (OI) 4

4 M| equiv(OI 119862119878119870119862119872119895larr997888997888997888rarr 119872) 5

G3M| equivOI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874

M⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 from message M2 1

1 R1 M| equivM⊲ OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 2

2 R6 A3 M| equivM has OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 3

3 R4 A7 M| equivM⊲(OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T) 4

4 M| equiv OI (OI C119878119870119862119872119895larr997888997888997888rarr 119872) (OI 119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874) T119872

119878119870119872119874119895larr997888997888997888rarr 119874 5

G4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874

O⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 from message M3 1

1 R1 O| equivO⊲YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 2

2 R6 A4 O| equivO has YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 3

3 O| equivO ⊲ (YesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)) 4

4 O| equivYesNo (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874 5

G5 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872)

C⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) from message M3 1

1 R1 C| equivC⊲(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 2

2 R2 A6 C| equivC has (119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 3

3 R5 C| equivC has (Yes OI) 4

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 20: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

20 Wireless Communications and Mobile Computing

4 C| equiv(Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) 5

G6 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874

C⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 from message M4 1

1 R1 C| equivC⊲AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 2

2 R6 A5 C| equivC has AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 3

3 C| equivC⊲(AcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)) 4

4 C| equivAcceptReject Yes CLRM (Yes OI 119862119878119870119862119872119895+1larr997888997888997888997888rarr 119872) (OI119872

119878119870119872119874119895+1larr997888997888997888997888997888rarr 119874)119862

119878119870119862119874119895+1larr997888997888997888997888rarr 119874 5

The goals are successfully proved in the Making PaymentPhaseThus it can be concluded that all parties have satisfieda secure mutual authentication

7 Conclusion

In this paper we have introduced protocols for mobilepayments that satisfy the important attributes of both strongfairness and security of sale transactions Those securityproperties include confidentiality integrity mutual authen-tication and nonrepudiation The notion of our approach issuitable for the existing SMS infrastructure This is becausehash functions have been employed which keep the sizesof all messages small enough to fit the limitation of theSMS system Moreover our protocols have deployed thetechniques of offline session key generation and distributionto create the transaction security while being able to retainthe lightweight property Based on our analysis it has beenproven that our protocols are more effective than othersin terms of information security and strong fairness ofthe exchange All of our protocols have been successfullyanalyzed using the Scyther and BAN logic tools to verify theircompleteness and soundness

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work has been funded by Faculty of Information Scienceand Technology Mahanakorn University of TechnologyBangkok Thailand

References

[1] N Saxena and N S Chaudhari ldquoEasySMS A protocol forend-to-end secure transmission of SMSrdquo IEEE Transactions onInformation Forensics and Security vol 9 no 7 pp 1157ndash11682014

[2] M Toorani and A A B Shirazi ldquoSSMS - A secure SMSmessaging protocol for the m-payment systemsrdquo in Proceedings

of the 13th IEEE SymposiumonComputers andCommunicationsISCC 2008 pp 700ndash705 mar July 2008

[3] N Saxena and N S Chaudhari ldquoSecureSMS A secure SMSprotocol for VAS and other applicationsrdquoThe Journal of Systemsand Software vol 90 no 1 pp 138ndash150 2014

[4] A Biryukov A Shamir and D Wagner Real time cryptanalysisof A51 on a PC 2007 httpscryptomeorga51-bswhtm

[5] A Pourali M V Malakooti and M H Yektaie ldquoA secureSMS model in e-commerce payment using combined AES andECC encryption algorithmsrdquo Society of Digital Information andWireless Communication p 431 2014

[6] N R Kisore and S Sagi ldquoA secure SMS protocol for imple-menting digital cash systemrdquo in Proceedings of the InternationalConference on Advances in Computing Communications andInformatics ICACCI 2015 pp 1883ndash1892 ind August 2015

[7] S Bojjagani and V N Sastry ldquoSSMBP A secure SMS-basedmobile banking protocol with formal verificationrdquo in Proceed-ings of the 11th IEEE International Conference on Wireless andMobile Computing Networking and Communications WiMob2015 pp 252ndash259 are October 2015

[8] H Rongyu Z Guolei C Chaowen X Hui Q Xi and QZheng ldquoA PK-SIM card based end-to-end security frameworkfor SMSrdquo Computer Standards amp Interfaces vol 31 no 4 pp629ndash641 2009

[9] M Thomas and V Panchami ldquoAn encryption protocol forend-to-end secure transmission of SMSrdquo in Proceedings of theIEEE International Conference on Circuit Power and ComputingTechnologies ICCPCT 2015 ind March 2015

[10] A Alotaibi and H Aldabbas ldquoA review of fair exchangeprotocolsrdquo International Journal of Computer Networks amp Com-munications vol 4 no 4 2012

[11] A Paulin and T Welzer ldquoA universal system for fair non-repudiable certified e-mail without a trusted third partyrdquoComputers amp Security vol 32 pp 207ndash218 2013

[12] M Jakobsson ldquoRipping coins for a fair exchangerdquo LectureNotes in Computer Science (including subseries Lecture Notesin Artificial Intelligence and Lecture Notes in Bioinformatics)Preface vol 921 pp 220ndash230 1995

[13] A A Mohammed ldquoOwnership transfer protocolrdquo in Proceed-ings of the Internet Technology and Secured Transactions 2010

[14] R H Deng ldquoPractical protocols for certified electronic mailrdquoJournal of Network and Systems Management vol 4 no 3 pp279ndash296 1996

[15] A Abdullah and H Aldabbas ldquoDesign and evaluation of a newfair exchange protocol based on an online TTPrdquo InternationalJournal of Network Security amp Its Applications vol 4 no 4 pp21ndash36 2012

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 21: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

Wireless Communications and Mobile Computing 21

[16] J N Luo M H Yang and S-Y Huang ldquoAn Unlinkable Anony-mous Payment Scheme based on near field communicationrdquoComputers and Electrical Engineering vol 49 pp 198ndash206 2016

[17] J Liu and L Vigneron ldquoDesign and verification of a non-repudiation protocol based on receiver-side smart cardrdquo IETInformation Security vol 4 no 1 pp 15ndash29 2010

[18] W Fan H Shu E Fife and Q Yan ldquoAn enhanced-security fairE-payment protocolrdquo in Proceedings of the 2009 WRI WorldCongress on Computer Science and Information EngineeringCSIE 2009 pp 516ndash519 usa April 2009

[19] M Ben-Or O Goldreich S Micali and R L Rivest ldquoAfair protocol for signing contractsrdquo Institute of Electrical andElectronics Engineers Transactions on Information Theory vol36 no 1 pp 40ndash46 1990

[20] N AsokanM Schunter andMWaidner ldquoOptimistic protocolsfor fair exchangerdquo in Proceedings of the 1997 4th ACM Confer-ence on Computer and Communications Security pp 6ndash17 April1997

[21] AMAlaraj andMMunro ldquoEnforcing honesty in fair exchangeprotocolsrdquo Advanced Information and Knowledge Processingvol 52 pp 451ndash479 2010

[22] AMAlaraj ldquoPurchase of physical products onlinerdquo in Proceed-ings of the 2012 International Conference on Multimedia Com-puting and Systems (ICMCS) pp 937ndash940 Tangiers MoroccoMay 2012

[23] A M Alaraj ldquoFair certified email protocolrdquo InternationalJournal of Computer amp Technology vol 10 no 1 pp 1255ndash12602013

[24] R-J Hwang and C-H Lai ldquoProvable fair document exchangeprotocol with transaction privacy for e-commercerdquo Symmetryvol 7 no 2 pp 464ndash487 2015

[25] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

[26] C-L Chen H-Y Lin Y-Y Chen and J-K Jan ldquoA fairtransaction model in mobile commercerdquo in Proceedings of theSignal Processing and Information Technology pp 484ndash4892006

[27] M Burrows M Abadi and R Needham ldquoLogic of authentica-tionrdquo ACM Transactions on Computer Systems vol 8 no 1 pp18ndash36 1990

[28] CThammarat R Chokngamwong C Techapanupreeda and SKungpisdan ldquoA secure SMS mobile payment protocol ensuringfair exchangerdquo in IEE Proc The 29th CircuitSystems Computersand Communications pp 163ndash166 Thailand Phuket 2014

[29] S Kungpisdan and S Metheekul ldquoA secure offline key genera-tion with protection against key compromiserdquo in Proceedings ofthe 13th World Multi-Conference on Systemics Cybernetics andInformatics WMSCI 2009 Jointly with the 15th InternationalConference on Information Systems Analysis and Synthesis ISAS2009 pp 63ndash67 usa July 2009

[30] H Pagnia and F C Gartner ldquoOn the impossibility of fairexchange without a trusted third partyrdquo Technical Report TUD-BS-1999-02 Darmstadt University of Technology Departmentof Computer Science Darmstadt Germany 1999 pp 1-15

[31] O Dandash Y Wang P D Le and B Srinivasan ldquoFraudulentinternet banking payments prevention using dynamic keyrdquoJournal of Networks vol 3 no 1 pp 25ndash34 2008

[32] S Kungpisdan P D Le and B Srinivasan ldquoA limited-used keygeneration scheme for internet transactionsrdquo Lecture Notes inComputer Science vol 3325 2005

[33] H H Ngo X Wu P D Le C Wilson and B SrinivasanldquoDynamic key cryptography and applicationsrdquo InternationalJournal of Network Security vol 10 no 3 pp 161ndash174 2010

[34] S Kungpisdan B Srinivasan and P D Le ldquoLightweight mobilecredit-card payment protocolrdquo in Progress in cryptologymdashINDOCRYPT 2003 vol 2904 of Lecture Notes in Comput Scipp 295ndash308 Springer Berlin 2003

[35] A D Rubin and R N Wright ldquoOff-line generation of limited-use credit card numbersrdquo Lecture Notes in Computer Science(including subseries Lecture Notes in Artificial Intelligence andLecture Notes in Bioinformatics) Preface vol 2339 pp 196ndash2092002

[36] C Cremers ldquoThe scyther tool verification falsificationand analysis of security protocolsrdquo in Proceedings of theIEE on Computer Aided Verification pp 414ndash418 SpringerBerlinHeidelberg Germany 2008

[37] C Cremers and M Sjouke Operational semantics and verifica-tion of security protocols Springer Science BusinessMedia 2012

[38] C Patsakis KDellios andMBouroche ldquoTowards a distributedsecure in-vehicle communication architecture formodern vehi-clesrdquo Computers amp Security vol 40 pp 60ndash74 2014

[39] Q Cheng S Lu and J Ma ldquoAnalysis and improvement ofthe Internet-Draft IKEv3 protocolrdquo International Journal ofCommunication Systems vol 30 no 9 Article ID e3194 2017

[40] M Bilal and S Kang ldquoTime-assisted authentication protocolrdquoInternational Journal of Communication Systems p 16 2017

[41] Y Ma ldquoNFC communications-based mutual authenticationscheme for the internet of thingsrdquo International Journal ofNetwork Security vol 19 no 4 pp 631ndash638 2017

[42] NR Potlapally S Ravi A Raghunathan andNK Jha ldquoA studyof the energy consumption characteristics of cryptographicalgorithms and security protocolsrdquo IEEETransactions onMobileComputing vol 5 no 2 pp 128ndash143 2006

[43] D Mishra A K Das A Chaturvedi and S MukhopadhyayldquoA secure password-based authentication and key agreementscheme using smart cardsrdquo Journal of Information Security andApplications vol 23 pp 28ndash43 2015

[44] R Mishra and A K Barnwal ldquoA Privacy Preserving Secureand Efficient Authentication Scheme for Telecare MedicalInformation Systemsrdquo Journal of Medical Systems vol 39 no5 2015

[45] L Hu L Chi H-T Li W Yuan Y Sun and J-F ChuldquoThe classic security application in M2M The authenticationscheme of mobile paymentrdquo KSII Transactions on Internet andInformation Systems vol 6 no 1 pp 131ndash146 2012

[46] S Kungpisdan ldquoAccountability of centralized payment systemsFormal reasoning protocol design and analysisrdquo IETETechnicalReview vol 27 no 5 pp 351ndash364 2010

[47] Y Chen J Martınez P Castillejo and L Lopez ldquoA PrivacyProtection User Authentication and Key Agreement SchemeTailored for the Internet of Things Environment PriAuthrdquoWireless Communications and Mobile Computing vol 2017 pp1ndash17 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 22: A Secure Fair Exchange for SMS-Based Mobile Payment ...downloads.hindawi.com/journals/wcmc/2018/6953160.pdf · protocol. is protocol provides end-to-end SMS security and is able to

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom