1
3
A Secure M-Commerce System based on credit card transaction
4 5
6
Fang-Yie Leu
⇑, Yi-Li Huang, Sheng-Mao Wang
7 Department of Computer Science, TungHai University, Taiwan 89
1 1
a r t i c l e i n f o
12 Article history:
13 Received 15 March 2015 14 Accepted 8 May 2015 15 Available online xxxx 16 Keywords:
17 M-commerce 18 Binary adder 19 Data Connection Core 20 Secure Sockets Layer 21 Secure Electronic Transaction 22
2 3
a b s t r a c t
Nowadays the demands for wireless Internet shopping are increasing. But credit card fraud has been seri- 24 ous, and SET and SSL have their own problems. To enhance the security of online shopping, in this paper, 25 we propose a secure m-commerce scheme, called the Secure M-Commerce System (SMCS for short), with 26 which users can create a safe credit-card transaction for Internet shopping. Basically, the SMCS coordi- 27 nates the cash flow of a trading system and its credit card entities to effectively protect the issued trans- 28 actions against different attacks and avoid information leakage. The proposed system also employs a Data 29 Connection Core (DCCfor short) to link the card-issuing bank and consumers before their wireless com- 30 munication starts so as to significantly improve the security level of our m-commerce environment. 31 Theoretical analysis shows that the SMCS is more secure than SET and SSL. The performance analysis indi- 32 cates that the SMCS is indeed a feasible m-commerce system. 33
Ó2015 Published by Elsevier B.V. 34 35 36 37
38 1. Introduction
39 Recently, the convenience and security of wireless communica- 40 tion have been greatly improved (Nabi 2005). Many people enjoy 41 online shopping with their credit cards. But due to the infrastruc- 42 ture of a wireless system, the transactions issued are created via 43 wireless. On the other hand, credit card fraud nowadays is serious 44 (Mahmoudi and Duman 2015; Gold 2014), which significantly 45 reduces online shopping attraction for some people. Also, owing 46 to vigorous development of wireless networks, current mobile 47 devices, such as mobile phones, tablet PCs and laptops, have pro- 48 vided users with diverse features and services, which have colored 49 our everyday life and gradually changed people’s shopping habits.
50 Generally, a secure credit-card mechanism for m-commerce 51 should securely protect the corresponding transactions and per- 52 sonal information. At present, when shopping in a wireless envi- 53 ronment, e.g., to pay something by using the Secure Sockets 54 Layer (SSL), one must send the card number, expiration date and 55 other information to the merchant. In fact, SSL can ensure 56 peer-to-peer delivery safety, but it cannot confirm the identities 57 of the underlying users (Oppliger et al. 2008; Das and Samdaria 58 2014).
59 To solve this problem, the Card network organizations Visa and 60 MasterCard put forward an electronic payment system specifica- 61 tion for Secure Electronic Transaction (SET) (Lu and Smolka
1999). However, SET has its own problem, e.g., a consumers needs 62 to apply for a certificate (Bella et al. 2003). That means on user side, 63 the corresponding information of the credit card must be stored in 64 a hard disk. Also, to improve its security level, SET takes a long time 65 to calculate complicated asymmetric encryption and decryption 66 key (Shedid and Kouta 2010; Yong and Jindi 2010), thus giving 67 users an inconvenient m-commerce experience. Today, the 68 increasing demands for m-commerce motivate us to construct a 69 safe and convenient m-commerce mechanism. Therefore, in this 70 study, we propose a secure m-commerce scheme, named the 71 Secure M-Commerce System (SMCS for short) which coordinates 72 the cash flow of a trading system and credit card entities to 73 develop a safe and convenient m-commerce environment for users, 74 without increasing extra restrictions and resources on the cash 75 flow and credit card entities. Basically, we produce a credit-card 76 dynamic authentication code to substitute for the credit card infor- 77 mation so that the trading merchant cannot know the credit card 78 number and its details. The SMCS also employs a Data 79 Connection Core (DCCfor short) to link the card-issuing bank and 80 consumers before their wireless communication starts. 81 Furthermore, the card-issuing bank authenticates the credit card’s 82 dynamic authentication code and merchant’s dynamic authentica- 83 tion code rather than directly authenticating the credit card and 84 merchant information. This can efficiently make sure the legitima- 85 tion of the consumer and trading merchant so as to effectively 86 increase the security level of the SMCS. Theoretical analysis shows 87 that the SMCS is more secure than SET and SSL. The performance 88 analysis indicates that the SMCS indeed a feasible m-commerce 89 system. 90
http://dx.doi.org/10.1016/j.elerap.2015.05.001 1567-4223/Ó2015 Published by Elsevier B.V.
⇑ Corresponding author.
E-mail addresses:leufy@thu.edu.tw(F.-Y. Leu),yifung@thu.edu.tw(Y.-L. Huang), r79520@livemail.tw(S.-M. Wang).
Contents lists available atScienceDirect
Electronic Commerce Research and Applications
j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c a t e / e c r a
Please cite this article in press as: Leu, F.-Y., et al. A Secure M-Commerce System based on credit card transaction. Electron. Comm. Res. Appl. (2015),
91 The rest of this paper is organized as follows. Section2intro- 92 duces background and related work of this study. Section 3 93 describes the proposed system. Performance and security are ana- 94 lyzed and discussed in Section4. Section 5concludes this paper 95 and outlines our future studies.
96 2. Background and related work 97 2.1. Credit card transaction
98 Generally, the most important feature of a credit-card transac- 99 tion is to transform the relationship on trading from ‘‘seller to 100 buyer’’ into a series of contractual relations. Due to away from 101 face-to-face purchase, the authorization and security will be the 102 two major concerns. In such a transaction, after confirming the 103 identity of a buyer, the seller receives guaranteed payment from 104 the acquiring bank, and the acquiring bank also receives guaran- 105 teed payment from international organizations. The card-issuing 106 bank then judges the authorization of the payment based on the 107 payer’s up-to-date credit, and promises to fulfill the payment to 108 the international organizations. Finally, the credit card holder 109 (buyer) is obligated to settle the money with the card-issuing bank 110 based on his/her credit-card contract. This seemingly complicated 111 process, in fact, greatly simplifies the trading relationships 112 between buyers and sellers, because the time difference between 113 the payment and settlement system is no longer a problem, and 114 the information flow and cash flow are separated when the bank 115 and the new contractual relationship intervene (CreditCards.com, 116 http://www.creditcards.com/). Also, the corresponding informa- 117 tion flow can be recognized by the merchant immediately to 118 authorize the transaction. Although the seller is requested to pay 119 around 3% of total trading amount of price, this mechanism can 120 greatly increase sale opportunities.
121 Meanwhile, the merchant is licensed with a message to confirm 122 whether the transaction is completed, and authorization is only an 123 instant of the information flow. Regarding the cash flow, for each 124 day, all the network transactions from different participating 125 member banks will be calculated later by the international organi- 126 zations. After the member banks are recognized on the date of the 127 network shopping, they will use the ‘‘real-time gross settlement 128 system’’ to transfer the funds to the international organizations, 129 and the international organizations transfer funds to the 130 card-issuing bank. From this moment, you can say that the impor- 131 tance of the role a bank plays in this process is lower, since cash 132 flow is really performed sometimes later after the information 133 flow, and the purchase is completed after the accomplishment of 134 information flow. VISA proves a thing ‘‘the information of money 135 is sometimes more important than the money itself!’’
136 2.2. Secure Sockets Layer (SSL)
137 SSL has two main features. The first is the use of a public-key 138 and private-key mechanism to connect two sides of a network con- 139 nection. With this mechanism, they can securely exchange 140 encrypted messages with each other. The second is making use 141 of the third party certification to enable both sides of the connec- 142 tion to confirm each other’s information (Bicakci et al. 2014;
143 Badra and Urien 2004).
144 SSL secures electronic transaction specification by using the 145 consumer’s credit card number and expiration date or cardholder 146 relevant information as the certification parameters, and transmits 147 encrypted messages to the merchant. The merchant reuses the 148 encrypted messages to request card-issuing bank for payment.
149 The consumers prefer this way, because the system does not
request users applying for an electronic wallet and a safety certifi- 150 cation from the card-issuing bank. 151
But SSL has two shortcomings. The first is that the two sides of 152 an SSL connection can only determine whether or not the other 153 side is allowed to use the SSL mechanism. That means the con- 154 sumer does not know who the merchant is, a legitimate merchant 155 or a hacker. The merchant does not know the identity of the con- 156 sumer, either, and also cannot confirm whether the consumer’s 157 credit card number is correct or not (Bisel 2007). 158
The second is that although SSL is convenient for consumers to 159 perform Internet shopping through a wireless system, when SSL is 160 invoked by a transaction, the card number and cardholder’s related 161 information can be clearly seen on the merchant side, thus possibly 162 being unscrupulous businesses use. Besides, if the card number 163 and other relevant information are stolen by hackers, they may 164 be illegally used for Internet shopping, causing the loss upon not 165 only the cardholder, but also the merchant who would lose the 166 unpaid products if the cardholder submits relevant evidences to 167 deny this transaction. When SSL completes a transaction, the mer- 168 chant cannot determine whether this transaction is completed 169 before receiving the receipt from the funding or certified bank. 170 The SSL handshake process on Credit card transaction has four 171 stages (Zhao and Liu 2009; Du et al. 2009; Petridou and 172 Basagiannis 2012). In the first stage, consumer informs merchant 173 what version of the SSL, an encryption-algorithm list and a 174 compression-algorithm list that his/her terminal device supports. 175 The merchant chooses the highest versions of SSL, an encryption 176 algorithm and a compression algorithm for use. In the second 177 stage, the merchant sends his/her own certificate and Diffie– 178 Hellman’s public key to the consumer. In the third stage, the con- 179 sumer delivers its own certificate and Diffie–Hellman’s public key 180 to the merchant. With merchant’s (consumer’s) public key and 181 consumer’s (merchant’s) own private key, consumer (merchant) 182 can derive the Diffie–Hellman common secret key. In the fourth 183 stage, a message is transmitted from acquiring bank to the mer- 184 chant to prove that the key exchange and authentication process 185 has been successfully completed. 186
2.3. Secure Electronic Transaction (SET) 187
SET was jointly developed by the VISA, MasterCard, IBM and 188 other organizations (Venkataiahgari et al. 2006). Like SSL, it uses 189 the public key and private key as the basis to secure message 190 exchange process. However, SET requires that both consumer and 191 merchant apply for SET’s certification and obtain the SET’s elec- 192 tronic certification and software from card-issuing bank, and then 193 use the software to complete a transaction online. 194
The greatest advantage of SET, unlike that in SSL, is that both 195 trading sides of a connection can confirm each other’s identity. In 196 addition, SET can protect consumers’ credit data, since the mer- 197 chant only requires the consumer’s SET credential before it can bill 198 the card-issuing bank (Guan 2009; Li 2008; Sherif et al. 1998). 199
With the SET mechanism, if a consumer wants to transact, 200 his/her computer needs to install electronic wallet software 201 (Chaudhary et al. 2014), which like a real purse, is responsible 202 for the storage of electronic cash. Before the transaction, the con- 203 sumer has to first withdraw some amount of electronic cash from 204 the bank. The bank then verifies the identity of the consumer, 205 deducts the amount of money from the consumer’s account, and 206 deposits the amount of electronic cash to the consumer electronic 207 wallet. After that, the consumer can purchase goods from manufac- 208 turers or shops. The above process is not very friendly to consumer 209 since it is not an ‘‘enjoy-first-pay-later’’ mechanism. It has not 210 achieved the stage of convenience for m-commerce anywhere 211 (Chaudhary et al. 2014). 212
213 2.4. Binary adder
214 The binary adder, denoted by +2, is a new encryption method, 215 which adds two binary numbers of the same length. When 216 encrypting one of its two operandsX(which is the plaintext) with 217 the other operandK(which is the encryption key), it undergoes 218 normal binary addition ofX andKto generate ciphertextC, but 219 ignores the overflow bit. To decryptC, it comparesCandK. IfK 220 is smaller, it binary subtractsKfromC. Otherwise, it adds the two’s 221 complement ofKtoC. Also, assume that both the two binary num- 222 bersXandKarembits in length, then the probabilitypof recover- 223 ing the values of (X,K) from intercepted X+2 K on one trial is 224 p= 1/2m(Huang et al. 2013; Huang et al. 2015). This encryption 225 method provides a new choice for encrypting data (e.g.,X) by using 226 a keyK. If we employ both the binary adder and exclusive-or oper- 227 ators to encrypt data, the security level of the underlying system 228 will be greatly enhanced.
229 2.5. Data Connection Core (DCC)
230 From security viewpoint, in a wireless communication environ- 231 ment, there are two basic characteristics. (1) Wirelessly transmit- 232 ted messages are insecure since hackers, the wireless system’s 233 legitimate staffs and users can receive the messages at the same 234 time. (2) A wireless system needs to confirm the identities of those 235 presented correspondents. If the system and one of its users do not 236 have any link before their wireless communication, the two enti- 237 ties at the beginning of their communication cannot create a 238 secure channel for exchanging messages. Of course, the two enti- 239 ties also cannot mutually confirm each other’s identities by 240 exchanging safe messages. This will cause serious problems, like 241 credit card fraud or communication data leakage (Wei et al. 2013).
242 One of the methods to solve this problem is establishing an 243 identity authentication mechanism between the two entities 244 beforehand. We call the security mechanism the DCC, which is 245 used to pre-link the wireless system and its users. For different 246 security systems and communication mechanisms,DCChas differ- 247 ent contents. In this system,DCCis used to link the consumer and 248 card-issuing bank.
249 3. The proposed system
250 In this section, we will introduce the SMCS. Section 3.1 251 describes system parameters and functions employed in the 252 SMCS. Section3.2presents the system pre-procedure before wire- 253 less communication starts. Section3.3lists the trading steps and 254 their working principles.
255 3.1. System parameters and functions
256 3.1.1. Parameters
257 The system parameters utilized in the SMCS are listed below.
258 (1) UserID:consumer’s ID.
259 (2) e, d, N: RSA encryption/decryption keys for an individual
260 consumer.
261 (3) Card No:the credit card number of the consumer.
262 (4) CAK: the consumer’s authentication key.
263 (5) MAK: the merchant’s authentication key.
264 (6) BAK: the card-issuing bank’s authentication key.
265 (7) PW: the password given by the consumer.
266 (8) Kpw: the password key derived fromPWthrough a one-way 267 hash function.
268 (9) Data Connection Core: (DCC): the set of parameters that 269 pre-link the consumer and card-issuing bank.
On the mobile device side:UserID,e,N,KPW, CAK. 270
On the card-issuing bank side:UserID,e,d,N,Credit-Card No., 271
PW,KPW, CAK. 272273
274 (10)Xa, Xa1, Xa2, Xa3: the consumer’s private keys. 275
(11)PXa: the consumer’s public key. 276 (12)Xb,Xb1: the merchant’s private keys. 277 (13)PXb: the merchant’s public key. 278
(14)CSK: the common secret key shared by the consumer and 279 merchant. 280
(15) Credit card’s dynamic authentication code: EAES(Xa3CAK; 281 Xa2). 282
(16) Merchant’s dynamic authentication code: EAES(Xa1MAK; 283 CSK). 284
(17) Consumer’s order number: the number generated by the 285 merchant for the consumer’s m-commerce order. 286
(18)Mdate, Mtime: the date and time on merchant side when it 287 receives the consumer’s m-commerce order. 288
(19)Pre-purchase items: the format is the consumer’s order 289 number//Mdate//Mtime//shopping list, where // represents 290 concatenation. 291
(20)Consumer’s order confirmation message: the format of this 292 message is the consumer’s order number//Mdate// 293 Mtime//merchant’s code, where the merchant’s code is an 294 authorization code issued by the merchant’s acquiring bank. 295 (21)Shopping association message: the format isconsumer’s order 296 confirmation message//business registration certifi- 297 cate//shopping items detail//total amount//merchant’s 298 acquiring bank’s code//POS No.//EAES(Xa1MAK;CSK), where 299 business registration certificate is issued by a trustable orga- 300 nization or government. 301
(22)M-commerce payment request message: the format is 302 CSK//Xa1//EAES(Xa1MAK; CSK)//consumer’s order confirmation 303 message//business registration certificate//total amount// 304 merchant’s acquiring bank’s code//POS No. 305
(23)Tnonce: the timestamp of current time. 306
(24)KCT: A current–time encryption key which is defined as a 307 sequence obtained by concatenating the following current– 308 time items, including nanosecond, second, minute, hour, 309 month, and year, and duplicating the above sequence again 310 when necessary to make |KCT| = the key length of the under- 311 lying system. 312
(25)Trading result message: indicating the trading success or fail- 313 ure. If it is trading failure, the reason is then generated and 314 added. 315
(26)Bdate,Btime: the date and time when the card-issuing bank 316 authorizes a transaction. 317
3.1.2. Functions 318
The functions employed by the SMCS are defined below. 319
(1) Exclusive-or operator: 320 Encryption:c=pK. 321 Decryption:p=cK 322 (2) Binary adder operator +2: 323
Encryption:c=p+2K, where plaintextpand encryption key 324 Kundergo the binary addition, ignoring the overflow bit. 325
Decryption: p¼c2K¼ cK; ifc=K 326 cþKþ1; ifc<K
where -2
denotes the binary subtraction, andKis the one’s comple- 327 ment ofK. 328
(3) RSA encryption/decryption function: 329
Encryption: RSA_En(x,e) =xemodN, wherex is a random 330 key. 331
Decryption: RSA_En(y,d) =ydmodN, wherey= RSA_En(x,e). 332
Please cite this article in press as: Leu, F.-Y., et al. A Secure M-Commerce System based on credit card transaction. Electron. Comm. Res. Appl. (2015),
333 (4) En1(a,b;x)= (xa)+2b, wherexis the a key to be protected, 334 andaandbare encryption keys.
335 InvEn1(a,b;y) = (y-2b)ais the inverse function of En1(), 336 wherey= En1(a,b;x).
337 (5) En2(a, b; str)= (s1a)+2 b // (s2a)+2 b// (s3a)+2 b//...//
338 (sna)+2b, in whichaandbare encryption keys andstr=s1 339 //s2//s3//. . .//sn.
340 InvEn2(a,b;Cstr)= (cs1-2b)a// (cs2-2b)a// (cs3-2b)a//
341 . . .// (csn-2b)a, in whichaandbare decryption keys and
342 Cstr= En2(a,b;str) =cs1//cs2//cs3//. . .//csn.
343 (6) EAES(yAK;x):xis the plaintext to be encrypted,yis a ran- 344 dom parameter, andAKis the authentication key. Each time 345 before encryption,yis first exclusive-oved withAKto gener- 346 ate a dynamic encryption key, which is utilized as the AES’s 347 parent key. Then x is encrypted by AES to generate 348 EAES(yAK;x).
349 For example: in this system, the credit card’s dynamic 350 authentication code EAES(Xa3CAK;Xa2) as shown inFig. 1is 351 generated by invoking AES and inputting the consumer’s 352 random dynamic keyXa2and the result of exclusive-oring 353 Xa3and the consumer’s authentication key CAK.
354 (7) OP_Code:In the SMCS, different messages are generated for 355 different purposes. Each message has its own unique opera- 356 tion code (OP_codefor short) to indicate the designate func- 357 tion of the message. It can reduce the authentication time 358 and complexity. Table 1lists definitions of the employed
359 OP_codes.
360 (8) Status:each subsystem installed in the consumer, merchant, 361 and card-issuing bank has its own internal parameter (i.e., 362 status), which is used to indicate the state that the SMCS will 363 achieve at the next moment. Whenstatusis used in conjunc- 364 tion withOP_Code, they can effectively improve system per- 365 formance on certification, and protect the underlying system 366 against replay attacks. Table 1also lists the statuses and 367 their descriptions.
368 (9) HMAC(K): a specific integrity function employing a crypto- 369 graphic hash function and a secret key K to produce a 370 hash-based message authentication code (HMAC for short) 371 which ensures accuracy, integrity, and non-repudiation of 372 the corresponding message (Naqvi and Akram 2011; Najjar 373 and Najjar 2006).
374
375 3.2. Pre-procedure
376 Each of card-issuing bank, merchant and consumer has its own 377 pre-procedure.
378 3.2.1. The card-issuing bank
379 The card-issuing bank initially submits an identity- 380 authentication-key application to the CA. CA generates an authen- 381 tication keyBAKand sends the key to the card-issuing bank. After
that, the card-issuing bank and CA establish a communication 382 channel by usingBAKand communicate with each other through 383 the channel. 384
3.2.2. The merchant 385
The merchant who has a qualified Business registration certifi- 386 cate issued by government (or a trustable organization) sends a 387 message to CA to apply for an identity authentication key. After 388 inspecting the application documents and confirming that the 389 merchant is a legitimate company, CA creates an authentication 390 keyMAKand deliveries the key to the merchant. After that, CA peri- 391 odically contacts the merchant to make sure the legitimation of the 392 merchant. 393
3.2.3. The consumer 394
The consumer’s pre-procedure has three steps. 395
(1) The consumer applying for theDCCfrom the card-issuing 396 bank. 397
The consumer applies for aDCCfrom the card-issuing bank 398 with over-the-counter service. But, the consumer needs to 399 provide his/her personal information, including user name, 400 personal ID, birthday, residence address, email address, pho- 401 tocopy of the front and back of him/her identity card (in 402 Taiwan), proof of financial statement and his/her own pass- 403
word (PW). 404405
(2) Generating theDCC 406
If the card-issuing bank confirms the identity of the credit 407 card owner, then depending on the consumer’s credit card 408 number and password, the bank creates the consumer’s 409 DCCs, issues the consumer’s DCC, i.e., (UserID, e, N, KPW, 410 CAK), to the consumer’s mobile device, and keeps the DCC 411 for the consumer, i.e., (UserID, e, d, N,Card No., PW, KPW, 412
CAK), in its local database. 413414
(3) The m-commerce APP program is downloaded to the mobile 415 device. 416
417 3.3. Trading steps and working principles 418
Fig. 2illustrates an overview of the communication steps of the 419 SMCS. Steps 1.1–1.4 comprise the m-commerce order confirmation 420 stage. Steps 2.1 and 2.2 are the m-commerce payment stage. The 421 card-issuing bank authorization stage includes Steps 3.1 and 3.2. 422 Step 4 itself is the electronic invoice delivery stage. 423
Pre-procedure for m-commerce: 424
(1) When the mobile device is in its standby mode, it activates 425 the m-commerce APP installed in it. 426
(2) Visiting and browsing the merchant’s web page under the 427 guidance of the APP. 428
429 Fig. 1.The process of generating the dynamic authentication code for a credit card.
Table 1
Definitions of employed OP-codes and the corresponding statuses.
OP_Code Status Description
1 1 M-commerce requirements
2 2 M-commerce reply
3 3 M-commerce order
4 4 M-commerce order confirmation
5 5 M-commerce payment request
6 6 M-commerce payment reply
7 7 Card-issuing bank payment
8 8 Electronic invoice
9 9 Completion of the transaction
430 3.3.1. The m-commerce order confirmation stage 431
432 Step 1.1: The consumer
433 After browsing the merchant’s web page, the consumer moves 434 all his/her favorite products into the shopping cart, and sends 435 a message, denoted by Message 1 carrying the shopping list, 436 to the merchant. The format of this message is as follows:
437 OP-code|PXa| shopping list,
438 in whichOP-code= 1, andPXais the consumer’s public key. Also, 439 the consumer’sstatus is set to 2.
440 Step 1.2: The merchant
441 After receiving this message, the merchant uses its own private 442 keyXband the consumer’s public keyPxato calculate the com- 443 mon secret key CSK, where CSK¼PXbXamod p, and sends a 444 m-commerce reply, denoted by Message 2, to the consumer.
445 The format of Message 2 is as follows:
446 OP-code|PXb|CSKXb1|En2(CSK, Xb1; pre-purchase items)|HMAC 447 (CSK +2Xb1),
448 in whichOP-code= 2. The merchant then setsstatusto 3 as the 449 status of the consumer’s m-commerce order.
450 Step 1.3: The consumer 451
452 After receiving Message 2, the consumer checks to see whether 453 OP-code¼? status. If not, it discards this message and waits for a valid 454 one. Otherwise, the consumer knows that the message is a 455 m-commerce reply and then computesCSKwhereCSK¼PXaXbmod p.
456 The consumer further decryptsCSKXb1by usingCSKto obtainXb1 457 and verifies the message by checking to see whether HMAC 458 (CSK+2Xb1)c¼? HMAC(CSK+2Xb1)rwhere the subscriptcmeans that 459 the HMAC() is derived from the consumer’s internal parameters, 460 and the subscriptrrepresents that the HMAC() is retrieved from 461 Message 2. If they are not equal, the consumer discards this message 462 and waits for a valid one. Otherwise, the consumer usesCSKandXb1to 463 decrypt En2(CSK,Xb1;pre-purchase items) to recover thepre-purchase 464 itemswhich include the consumer’s order number,Mdate,Mtimeand 465 shopping list. If the consumer does not confirm the list, the process 466 goes back to Step 1.1. Otherwise, the consumer sends Message 3 to 467 the merchant. The format of this message is as follows.
468 OP-code|consumer’s order number|En1(CSK, Xb1; Xa1)|En2(CSK, 469 Xa1; consumer name//delivery address//shopping items detail//- 470 consumer phone number)|HMAC(Xa1+2CSK)
in whichOP-code= 3. The consumer’sstatusis then set to 4. 471 Step 1.4: The merchant 472
473 When receiving Message 3, the merchant retrieves the 474 Consumer’s order number from this message and the consumer’s 475 status, and tests whetherOP-code¼? status.If not, the merchant dis- 476 cards the message and waits for a valid one. Otherwise, meaning 477 this is a m-commerce order, the merchant decrypts En1(CSK,Xb1; 478 Xa1) by usingCSKandXb1to obtainXa1, and certifies the message 479 by testing whether HMAC(Xa1+2CSK)c¼? HMAC(Xa1+2CSK)rwhere 480 the subscriptcmeans HMAC(Xa1+2CSK) is calculated by using the 481 merchant’s internal parameters, and the subscriptrrepresents that 482 HMAC(Xa1+2CSK) is retrieved from Message 3. If they are not 483 equal, the merchant discards this message and waits for a valid 484 one. Otherwise, the merchant usesCSKandXa1to decrypt the mes- 485 sage to obtain the consumer name, delivery address, shopping 486 items detail and consumer phone number. It then sends the 487 m-commerce order confirmation message (Message 4) to the con- 488 sumer. The format of Message 4 is as follows. 489
OP-code|En2(Xa1, Xb1; shopping association message)|HMAC 490 ((CSKXb1)+2Xa1) in which OP-code= 4. The merchant’s status is 491 set to 5. 492
3.3.2. The m-commerce payment stage 493
494
Step 2.1: The consumer 495496
When receiving Message 4, the consumer tests whetherOP-code 497
¼? status.If not, the consumer discards the message and waits for a 498 valid one. Otherwise, showing that the message is the 499 m-commerce order confirmation, the consumer certifies the 500 message by testing whether HMAC((CSKXb1)+2Xa1)c ¼? HMAC 501 ((CSKXb1)+2Xa1)r where the subscripts c and r are respectively 502 the same as those mentioned above. If they are not equal, the con- 503 sumer discards this message and waits for a valid one. Otherwise, 504 he/she usesXa1andXb1to dcrypt En2(Xa1,Xb1;shopping association 505 message) to obtainshopping association messagewhich contains the 506 consumer’s order confirmation message, business registration certifi- 507 cate, shopping item detail, total amount, merchant’s acquiring 508 bank’s code, POS No., and EAES(Xa1MAK; CSK). If the consumer 509 Fig. 2.The communication steps of the SMCS.
Please cite this article in press as: Leu, F.-Y., et al. A Secure M-Commerce System based on credit card transaction. Electron. Comm. Res. Appl. (2015),
510 confirms the information and is ready to purchase, the 511 m-commerce APP will ask the consumer to input his/her own pass- 512 word (PW), accordingly compute the corresponding password key 513 Kpw,c based on the established algorithms beforehand and then 514 compare the key withKpw, i.e., the consumer’s password key stored 515 in theDCC. If they are not equal, the APP asks the user to input the 516 password again. If the user cannot pass the authentication for three 517 times, the system will shut off the m-commerce APP. If login is suc- 518 cessful, the consumer sends the m-commerce payment request 519 message, denoted by Message 5, to the card-issuing bank. The for- 520 mat of this message is as follows.
521 OP-code|Tnonce|UserID|RSA_En(Xa2,e)|En1(Xa2, Xa2Kpw; Xa3)|En2 522 (Xa2, Xa3KCT; m-commerce payment request message)|Xa1EAES 523 (Xa3CAK, Xa2)|HMAC((CSKXa2)+2Xa3) in which OP-code= 5. The 524 consumer’sstatusis set to 6.
525 Step 2.2: The card-issuing bank 526
527 Upon receiving Message 5, the card-issuing bank retrieves the 528 consumer’sstatus(the value is 5) stored in the card-issuing bank’s 529 system based on theUserID, and tests whetherOP-code¼?status(the 530 first authentication). If not, the card-issuing bank discards the mes- 531 sage and waits for a valid one. Otherwise, the card- issuing bank 532 verifiesTreceivedTnonce<DT(the second authentication). If not, it 533 discards the message. If yes, it derives KCT from Tnonce. 534 Furthermore, by UserID, the card-issuing bank retrieves the con- 535 sumer’s RSA encryption/decryption key (e, d, N) from the con- 536 sumer’s DCC, decrypts RSA_En(Xa2,e) to obtain Xa2, decrypts 537 En1(Xa2,Xa2Kpw;Xa3) by usingXa2andKpwto recoverXa3, and at 538 last decrypts En2(Xa2,Xa3KCT;m-commerce payment request mes- 539 sage) by utilizingXa2,Xa3andKCTto obtain them-commerce payment 540 requestmessage which conveysCSK,Xa1, EAES(Xa1MAK,CSK),con- 541 sumer’s order confirmation message (from which to retrieve con- 542 sumer’s order number), business registration certificate, total 543 amount, merchant’s acquiring bank’s code and POS No. It performs 544 the third authentication by testing whether HMAC((CSKXa2) 545 +2Xa3)c ¼? HMAC((CSKXa2)+2Xa3)r. If they are not equal, the bank 546 discards this message and waits for a valid one. Otherwise, accord- 547 ing to the business registration certificate, the card-issuing bank 548 retrievesMAKfrom its database. IfMAKdoes not exist in its database, 549 the bank will ask CA forMAK, and store it in the card-issuing bank’s 550 database. After obtainingMAK, the card-issuing bank performs the 551 fourth authentication by checking to see whether EAES(Xa1MAK, 552 CSK)c¼? EAES(Xa1MAK,CSK)r. If they are not equal, it discards this 553 message and waits for a valid one. Otherwise, the card-issuing bank 554 usesXa1to decryptXa1EAES(Xa3CAK,Xa2) carried in Message 5 to 555 obtain the credit card’s dynamic authentication code 556 EAES(Xa3CAK,Xa2)r, retrievesCAKfrom the consumer’sDCCto gener- 557 ate EAES(Xa3CAK,Xa2)c, and then performs the fifth authentication 558 by testing whether EAES(Xa3CAK,Xa2)c¼? EAES(Xa3CAK,Xa2)r.If they 559 are not equal, the bank discards the message and waits for a valid 560 one. Otherwise, the bank retrieves the consumer’s credit card num- 561 ber from the consumer’sDCC. After checking the consumer’s credit, 562 the card-issuing bank determines whether to authorize the transac- 563 tion. Also, no matter whether the transaction is successfully autho- 564 rized or not, the card-issuing bank will inform the consumer of the 565 trading results by sending the m-commerce payment reply 566 (Message 6) to the consumer. The format of Message 6 is as follows.
567 OP-code|En2(CSK, Xa1;consumer’s order confirmation message//- 568 trading results message//Bdate//Btime) |HMAC(Xa3Xa2), in which 569 OP-code = 6. The card-issuing bank further sends Message 7 to the 570 acquiring bank. The acquiring bank will transfer this message to 571 inform the merchant of the trading results. If the transaction fails,
the card-issuing bank provides reasons for the failure in Message 7. 572 The format of this message will be described later. 573
When receiving Message 6, the consumer tests whetherOP-code 574
¼? status. If not, the consumer discards the message and waits for a 575 valid one. Otherwise, meaning the message is the m-commerce 576 payment reply, the consumer certifies the message by testing 577 whether HMAC(Xa3Xa2)c¼? HMAC(Xa3Xa2)r. If they are not equal, 578 the consumer discards this message and waits for a valid one. 579 Otherwise, the consumer employsCSKandXa1to decrypt the mes- 580 sage to obtain the consumer’s order confirmation message, trading 581 results message,BdateandBtime. If the transaction fails, the reason 582 for the failure is shown and this transaction is terminated. 583 Otherwise, the consumer setsstatus= 8, and waits for the mer- 584 chant to send the electronic invoice. 585
3.3.3. The card-issuing bank authorization stage (via a wired 586 communication channel) 587
588
Step 3.1: The card-issuing bank 589590
The card-issuing bank payment message (Message 7) is sent by 591 the card-issuing bank to the acquiring bank via a wired credit-card 592 communication channel. Therefore, the message and content are 593 encrypted by using the channel’s encryption method. The format 594 of this message is as follows. 595
OP-code|consumer’s order confirmation message|POS No.|trading 596 results message|card number|authorization code|total amount|Bdate 597
|Btime 598
In whichOP-code= 7. 599
Step 3.2: The acquiring bank 600
601 When the acquiring bank receives Message 7, it identifies the 602 merchant of this transaction based on the merchant’s code and 603 POS No., and then transfers the message to the merchant to inform 604 him/her of the trading results (Message 8). The format of this mes- 605 sage is as follows: 606
OP-code|consumer’s order confirmation message|authorization 607 code|trading results message|Bdate|Btime|POS No. 608
In which OP-code= 7. When receiving the message, this mer- 609 chant retrieves this transaction’s statusaccording to theconsumer’s 610 order number(carried inconsumer’s order confirmation message), 611 and tests whetherOP-code¼? status. If not, the merchant discards 612 the message and waits for a valid one. Otherwise, the merchant 613 knows that the message is the card-issuing bank payment, which 614 includes the trading results. If the transaction fails, the merchant 615 terminates this transaction. Otherwise, products and the electronic 616 invoice are shipped to the consumer by executing Step 4. 617
3.3.4. The electronic invoice delivery stage 618
619
Step 4 The merchant 620621
The merchant sends the electronic invoice (Message 9) to the 622 consumer. The format of this message is as follows: 623
OP-code|electronic invoice|HMAC(CSK +2Xa1Xb1) 624
in whichOP-code= 8. The merchant also setsstatusof the con- 625 sumer’s order number to 9. After receiving the message, the con- 626 sumer tests whether OP-code ¼? status. If not, the consumer 627 discards the message and waits for a valid one. Otherwise, the con- 628 sumer tests whether HMAC(CSK +2Xa1Xb1)c ¼? HMAC(CSK 629 +2Xa1Xb1)r.If not, the consumer discards the message and waits 630 for a valid one. Otherwise the consumer saves the electronic 631 invoice, and sets status = 9 to complete this transaction. 632
633 4. Performance and security analyses
634 In the following, we will analyze and discuss features of the 635 SMCS on security and performance.
636 4.1. Performance evaluation
637 The SMCS was simulated in a card-issuing-bank-consumer–mer 638 chant environment. The program is developed by using Java. The 639 hardware specifications of the test-bed are listed inTable 2.
640 The simulation includes the internal-key generation, 641 communication-key generation and message generation given dif- 642 ferent key lengths, including 512, 768 and 1024 bits, and different 643 keys, including consumer’s private keys (Xa,Xa1,Xa2andXa3), mer- 644 chant’s private keys (XbandXb1), Diffie–Hellman PKDS public keys 645 (PXaand PXb), common secret key (CSK) and current–time encryp- 646 tion key (KCT).
Table 3lists the simulation results, in which the times required 647 to generate private keys and current–time encryption key were 648 small, but the times consumed to generate Diffie–Hellman PKDS 649 public keys and common secret key are relatively long, indicating 650 that they are the dominated factors for the SMCS performance. 651
Table 4 illustrates the timings required to execute different 652 operators and functions utilized in this study, including 653 exclusive-or, binary adder, binary subtract, En1(), En2(), HMAC(), 654 RSA() and EAES(). We can see that HMAC(), RSA() and EAES() con- 655 sume the longest times, indicating that we have to reduce their 656 usage to improve the system performance. 657
The numbers of operations required to produce data carried in a 658 message are shown inTable 5. This table also lists the computation 659 times for the generation of a message given 512, 768, and 1024 bits 660 as the key lengths. Since Message 1 conveys OP_code, PXa, and 661 shopping list, the time consumed is almost equal to the time 662 required to produce PXa. Other messages have the similar 663 phenomenon. 664
Basically, Message 5 is strongly related to the security of pay- 665 ment information. It needs to be securely protected. So this mes- 666 sage is generated spending the longest time among all messages. 667 Message 6 generated by the card-issuing bank and Message 9 pro- 668 duced by the merchant only use binary adder and exclusive-or, and 669 generate HMAC(). So their generation times are short. Message 7 670 and Message 8 are transmitted through the credit card system’s 671 wired communication channel so we did not analyze them in this 672 study. That is why they do not appear inTable 5. 673
4.2. Security evaluation 674
The SMCS has the following nine features which make a 675 m-commerce system more secure, efficient and convenient. 676
(1) When a wireless communication environment is available, 677 users, even outdoor, can use the SMCS to conduct 678 m-commerce, meaning it is a convenient shopping 679 environment. 680
(2) The merchant does not know the consumer’s credit card 681 number and its related information, and the card-issuing 682 bank does not know the consumer’s order list. Thus, the 683 shopping behavior has been highly secured. 684
Table 2
The specifications of the test-bed utilized to simulate the consumer device, merchant and card-issuing bank.
Component Card-issuing bank Consumer Merchant CPU Intel i7-950
3.07 GHz
Intel i5 2.67 GHz
Intel i7-950 3.07 GHz
RAM 12 GB 2 GB 12 GB
Platform Windows 7, 64-bit Windows 7, 32-bit
Windows 7, 64-bit
Table 5
The operations that constitute a message in the SMCS encryption/decryption processes and computation times for the generation of messages.
Message Number of operations Time consumed
(ms) Size (bits) 512 768 1024 Message
1
R+D 0.76 2.33 4.99
Message 2
2R+D+C+X+ En2 +H+B 0.77 2.19 4.58 Message
3
En1 +C+R+ En2 +H+B 2.68 8.06 17.83 Message
4
En2 + EAES+H+ 2X+B 0.06 0.06 0.08 Message
5
RSA + En1 + 2R+ En2 +T+ 5X+ EAES+H+B 2.71 8.02 17.62 Message
6
En2 +X+H 0.04 0.04 0.05
Message 9
H+B+X 0.04 0.04 0.05
R: random number generation;D: Diffie–Hellman public key generation;C: com- mon secret key (CSK) generation;X: exclusive-or operation;B: binary addition;S:
binary subtraction;T:KCTgeneration;H: HMAC() generation; RSA: RSA() encryp- tion; En1: En1() encryption; En2: En2() encryption; EAES: EAES() encryption.
Table 3
The timings required to generate the internal keys and communication keys on the card-issuing bank, consumer and merchant ends in the SMCS (–: does not exist).
Key Key generation time (ls)
Consumer Merchant and card-issuing
bank Size (bits)
512 768 1024 512 768 1024
Xa 0.52 0.71 0.95 – – –
Xa1 0.52 0.71 0.91 – – –
Xa2 0.55 0.70 0.91 – – –
Xa3 0.52 0.75 0.90 – – –
Xb – – – 0.50 0.67 0.82
Xb1 – – – 0.47 0.67 0.81
PXa 762.32 2331.59 4991.25 – – –
PXb – – – 175.13 495.98 1002.35
CSK 2563.11 7935.23 17691.32 552.71 1652.26 3531.44
KCT 3.69 3.87 4.00 – – –
Table 4
The timings required to calculate different operators and functions utilized in the SMCS.
Function or operator
Key generation time (ls)
Consumer Merchant and card-
issuing bank Size (bits)
512 768 1024 512 768 1024
0.21 0.27 0.37 0.14 0.20 0.23
+2 0.71 1.05 1.44 0.49 0.71 0.93
-2 1.95 2.83 3.65 0.84 1.22 1.59
En1() 0.87 1.30 1.69 0.64 0.87 1.13
En2() 2.70 3.81 5.00 1.74 2.50 3.28
HMAC() 112.31 125.09 139.6 39.81 41.36 47.76
RSA() 2512.36 7801.25 17385.91 – – –
EAES() 79.31 81.11 87.94 23.90 24.81 27.46
Please cite this article in press as: Leu, F.-Y., et al. A Secure M-Commerce System based on credit card transaction. Electron. Comm. Res. Appl. (2015),
685 (3) A consumer links himself/herself to the card-issuing bank 686 with the consumer’s DCC, thus forming a closed-security 687 architecture to protect the m-commerce environment.
688 (4) Through CA certification, the SMCS ensures the legality of a 689 merchant (rather than a faked one) to protect the interests 690 and shopping behaviors of consumers.
691 (5) As an open architecture between a consumer and a mer- 692 chant, the SMCS uses Diffie–Hellman PKDS to establish a safe 693 and convenient security mechanism for the two entities to 694 communicate with each other.
695 (6) The encryption function En2(a, b; str) is used to encrypt 696 plaintext streamstr. Such a two-dimensional stream cipher 697 scheme can effectively improve the security of a stream 698 cipher technique.
699 (7) CAKandMAK, which serve as mother keys, are derived from 700 the credit card’s and merchant’s dynamic authentication 701 codes, thus greatly enhancing the safety of m-commerce 702 since the two codes are highly secured.
703 (8) In the SMCS, all delivered messages, except the one sent in 704 Step 1, are protected by HMAC(Kd), in which the keyKdis 705 derived from the dynamic linking keys created by the two 706 sides of a wireless connection for securing messages trans- 707 mitted between them so as to ensure the communication 708 privacy, integrity, non-repudiation and mutual authentica- 709 tion of the delivered messages.
710 (9) The security of Message 5 determines whether the payment 711 request is securely transmitted or not. So this message needs 712 to be protected by PW. In fact, it has five authentication 713 mechanisms, including authenticating OP-code, checking 714 Tnonce, verifying HMAC(), certifying merchant and certifying 715 consumer. Therefore, we can ensure that Message 5 is a 716 legitimate m-commerce payment request. This also ensures 717 safety of the SMCS.
718
719 In the SMCS, the security mechanism employed at the 720 m-commerce order confirmation stage is the Diffie–Hellman PKDS 721 which is very difficult to be cracked (Leu et al., 2010). Hence, the 722 generated communication keys including CSK, Xa1 and Xb1 are 723 secure. However, the information of the pre-purchase items (rather 724 than the items themselves), including consumer name//delivery 725 address//shopping item data//consumer phone number and the 726 shopping association message, is protected by En2(). The security 727 levels of En1() and En2() will be analyzed in Theorem 1 under the 728 assumption that the keys used in the SMCS are alln-bits in length 729 wheren= 128, 256, 512, 1024 or 2048.
730 Theorem 1. Let y = En1(a, b; x) be the ciphertext key generated by 731 encrypting plaintext key x with encryption keys a and b. If (plaintext, 732 ciphertext) pair, denoted by (x, y), is known by hackers, the probability 733 with which hackers can obtain the correct encryption pair, i.e., (a, b), is 734 1/2n. Furthermore, if only the ciphertext key y is known by hackers, the 735 plaintext key x is also practically secure.
736 Proof. First, we rewritey= En1(a,b;x) = (ax) +2bas 737
y2b¼ax ð1Þ
739 739
740 in which two linearly independent unknown keys a and b are 741 employed to encrypt known keys xandy with two operators 742 and +2. For each unknown key, there are 2npossible values, imply- 743 ing that for each known pair (x,y), there are 2npossible pairs of (a, 744 b)s that satisfy Eq.(1)since for eacha(b), there exist 2nbs (as) that 745 make Eq. (1) true. Hence, the probability with which to crack 746 En1(a,b;x) when (plaintext, ciphertext) pair is known and then 747 obtain the correct (a,b) pair is21n.
Furthermore, if only the ciphertext keyyis known by hackers, 748 Eq.(1)can be rewritten as 749
750
x¼ ðy2bÞ a ð2Þ 752752
in whichxis derived from three keys, i.e.,a,bandy, by using -2and 753 operators. For each known ciphertext keyy, there are (2n)2= 22n 754 possiblea,bandxkey-combinations that meet Eq.(2)since when 755 one of the three parameters, e.g.,x, is known, there are 22n(b,y) 756 pairs that will satisfy Eq.(2). Hence, the probability with which to 757 obtain the correct value of (a,b, x) triple from knownyis212n. In other 758 words, when hackers know ciphertexty, the probability with which 759 they can obtain correct plaintextxby breaking Eq.(2)is212nwhich is 760 less than21n, the probability of a blind guess onxon one trial. Hence, 761 plaintext keyxpractically secure, even though ciphertext keyyis 762 known by hackers. (QED) h 763
In En2(a,b;str), like that in En1(a,b;x), the encryption keys are 764 alsoaandb. But the plaintextstr = p1//p2//. . .//pmis a stream con- 765 junction keys, meaning a sub-streamPiconjunctively exists with 766 other sub-streams Pj, rather than an independent one. So the 767 ciphertext is also a stream conjunction keys, i.e.,Cstr= En2(a,b; 768 str) =c1//c2//. . .//cmwhere 769
770 Cj¼ ðapjÞþ2b; 15j5m ð3Þ 772772 In the SMCS, each time when En2(a,b;str) is invoked, the plaintext 773 stris protected by randomly generated encryption key pair (a,b). 774 Hackers only know the ciphertext streamCstrand do not know 775 (a, b). Then, by Theorem 1 and Eq. (3), the plaintext stream 776 p1//p2//. . .//pmis well protected. 777
When the consumer completes the e-commerce order confirma- 778 tion stage, he/she may start the transmission of the m-commerce 779 payment request, i.e., Message 5, or delay/cancel this 780 m-commerce. In Message 5, the random keyXa2is protected by 781 using RSA_En(Xa2, e) which is sufficiently secure since the RSA 782 encryption key pair (e, N) is a part of the consumer’sDCC. Hence, 783 hackers cannot acquire it. Moreover, the random keyXa3 is pro- 784 tected by En1(Xa2,Xa2KPW;Xa3) and is also sufficiently secure since 785 by Theorem 1, hackers do not knowXa2andXa2KPW. Thus, the ran- 786 dom keysXa2andXa3that link the consumer and the card-issuing 787 bank are securely protected when they are carried in Message 5. 788
Also, in Message 5, the credit card’s dynamic authentication 789 code EAES(Xa3CAK; Xa2) is protected by Xa1. However, even if 790 EAES(Xa3CAK;Xa2) is known by hackers, the consumer’s authentica- 791 tion keyCAKis still secure. Any forged Message 5 will not pass the 792 authentication performed by the card-issuing bank. Theorem 2 will 793 show this. 794
Theorem 2. In the SMCS, the security mechanisms of the 795 m-commerce payment request, i.e. Message 5, can effectively defend 796 three common attacks, i.e., forgery attack, replay attack and eaves- 797 dropping attack. 798
Proof.First, anyone, including a hacker, who does not haveDCC, 799 will not own (e, N) andKPW, implying that the encryption codes, 800 RSA_En(Xa2, e) and En1(Xa2,Xa2Kpw; Xa3), generated by hackers 801 cannot be correctly decoded by the card-issuing bank. That is, 802 Xa2,h–Xa2,bandXa3,h–Xa3,bwhere subscripth(b) represents that 803 the random keysXa2andXa3are generated by hackers (obtained 804 by card-issuing bank through decoding). Hence, the two 805 forged authentication codes, i.e., HMAC((KCTXa2)+2Xa3) and 806 EAES(Xa3CAK, Xa2), carried in Message 5 cannot pass the authenti- 807 cation performed by the card-issuing bank. That is, the 808 m-commerce payment request can effectively defend the forgery 809 attack. 810
