可預防雙重支付的離線小額匿名交易機制 - 政大學術集成

全文

(1)國立政治大學資訊科學系 Department of Computer Science National ChengChi University. 碩士論文政治. 大. ‧. ‧ 國. 學. 立 Master’s Thesis. y. Nat. er. io. sit. 可預防雙重支付的離線小額匿名交易機制 n. a l Micro-payment Protocol Anonymous Off-line i v with Double n U engchi Spending Prevention. Ch. 研究生 : 林承毅指導教授 : 左瑞麟中華民國 105 年 11 月.

(2) 摘要近年來手機的普及率日漸增加，手機逐漸成為生活中不可或缺的工具，因此許多生活方式逐漸的偏向由手機端完成，例如:找路不需要再透過地圖,上網查資料不需要再透過電腦，人們逐漸地把實體錢包轉向利用手機支付的電子錢包，像是中國支付寶等支付系統。利用手機當作錢包已經是現今手機發展的主要方向，然而對於手機的安全支付議題也日漸重視，近年來有安全晶片的保護下使用者的手機安全也有一定程度的提升，但是在離線交易的情況下惡意使用者的操作依然是可以欺騙安全晶片並製造出雙重支付的問題。. 政治大 2016 年陳等人提出了一個基於 NFC 系統的匿名行動付款協定，然而該協定立. 中必須要有銀行端的介入才能執行交易。在本論文中，我們基於陳等人的線上交. ‧ 國. 學. 易協定為基礎下發展了本篇論文的新交易協定，此交易協定可以適用於離線以及. ‧. 線上的環境。. Nat. sit. y. 離線環境下的雙重支付行為一直交易的過程中難以預防的攻擊，在本篇論文中我. n. al. er. io. 們透過安全晶片、符號化和本論文研究的雜湊鍊來預防雙重支付行為，且能保障使用者在交易過程中的匿名性。. Ch. engchi. i n U. 關鍵詞: 雙重支付, NFC, 離線交易, 安全交易, Token. v.

(3) Abstract As the coverage of mobile phone has been constantly increased in recent years, the mobile phones have become an indispensable tool in life. Many ways of lives are gradually done through the mobile terminals, for example: No longer need to find the way through the map or search information through the computer, people have also gradually turned to electronic payment via e-wallets instead of paying via physical wallets, such as AliPay in China. Adopting the mobile phone as a wallet is nowadays the main development direction of mobile phones. Meanwhile, people are paying. 政治大. more and more attention to the topics on the security of mobile payment than before.. 立. In recent years, under the protection of secure element, the security of users’ mobile. ‧ 國. 學. phone has been enhanced to a certain extent. In the case of off-line transactions, malicious users are capable of fooling secure element and making double spending.. ‧ sit. y. Nat. In 2016, Chen et al. proposed a NFC-Based anonymous mobile payment protocol. In. io. al. er. that protocol the transaction can only be executed with the involvement of issuer. In this research, we introduce a new protocol which can support both on-line and off-line. n. v i n C h from that of Chen transactions. Our protocol is modified e n g c h i U et al.’s idea.. In our protocol, to prevent a malicious user, we use a secure element which stores sensitive information that cannot be altered by the user. In this way, the cheating behavior of a malicious user can be prevented. On the other hand, by using the token techniques, the anonymity of a user can be achieved from the view of a merchant. In this study, we focus on the prevention of double spending attack during off-line transaction. We used hash chain to verify the correctness of transactions and prevent the double spending. Key words: Double Spending, NFC, Off-line Payment, Secure Payment, Token.

(4) Table of Contents 1.. Introduction ....................................................................................................................... 8. 2.. Background Knowledge .................................................................................................. 13 2.1. Near Field Communication (NFC)......................................................................... 13. 2.2. Secure Element (SE) .............................................................................................. 13. 2.3. EMV....................................................................................................................... 14. 2.4. Token Payment ...................................................................................................... 15. 2.5. Off-line Payment .................................................................................................... 15. 2.6. Double-Spending ................................................................................................... 16. 2.7. ‧ 國. Chen’s Improvement on NFC-Based Anonymous Mobile Payment Protocol....... 34. ‧. 3.2. Architecture of the Proposed Scheme ............................................................................. 45. y. Initialization Stage ................................................................................................. 46. 4.2. Application for Virtual Credit Cards and Certificate Issuing Stage....................... 49. 4.3. Consumption Stage ................................................................................................ 59. 4.4. Payout Request Stage ............................................................................................. 67. al. er. sit. 4.1. n. 6.. He et al.’s EMV-based Offline Payment with Mutual Authentication .................. 18. io. 5.. 3.1. Nat. 4.. Related Works ................................................................................................................. 18. 學. 3.. 政治大 Token Payment ...................................................................................................... 16 立. Ch. engchi. i n U. v. Security Analysis ............................................................................................................. 69 5.1. Anonymity ............................................................................................................. 69. 5.2. Confidentiality ....................................................................................................... 70. 5.3. Prevention of Double Spending Attack.................................................................. 70. 5.4. Prevention of Insider Attacks ................................................................................. 73. 5.5. Non-Repudiation .................................................................................................... 73. 5.6. Comparison with Related Works and Protocol Limitation .................................... 74. EMV Compatible Instructions ......................................................................................... 76.

(5) 7.. Performance Analysis ...................................................................................................... 82. 8.. Conclusion ....................................................................................................................... 83. 9.. References ....................................................................................................................... 84. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v.

(6) List of Figures Figure 1. Overall process of the Token payment ....................................................... 17 Figure 2. Flow of the protocol ..................................................................................... 22 Figure 3. Contents of the off-line certificate application ............................................. 24 Figure 4. Flow chart of the off-line transaction ........................................................... 27 Figure 5. Contents of the transaction step .................................................................... 28 Figure 6. Flow chart of the merchant payout request stage ......................................... 31. 政治大. Figure 7. Contents of the merchant payout request stage ............................................ 31. 立. Figure 8. Information owned by each part on Initial stage .......................................... 37. ‧ 國. 學. Figure 9. Flow of applying for virtual accounts stage ................................................. 38. ‧. Figure 10. Flow of Applying for virtual transaction accounts ..................................... 40. sit. y. Nat. Figure 11. Flow of Updating virtual credit cards and optional virtual accounts ......... 42. io. al. er. Figure 12. Flow of applying for AID ........................................................................... 52. n. Figure 13. Flow of TSP access user’s SE .................................................................... 54. Ch. engchi. i n U. v. Figure 14. Block 1........................................................................................................ 55 Figure 15. Flow of applying for TID and virtual credit cards...................................... 58 Figure 16. TBC after the merchant verified ................................................................. 60 Figure 17. TBC after SE signed ................................................................................... 61 Figure 18. Flow of Off-line transaction ....................................................................... 62 Figure 19. Flow of On-line verify and request payment part ...................................... 65 Figure 20. TBC after the first time consumption ......................................................... 67 Figure 21. Flow of payout request ............................................................................... 68.

(7) Figure 22. Flow chart of User try to fake the transaction block. ................................. 72 Figure 23. Flow chart of EMV compatible instructions (off-line part) ....................... 79 Figure 24. Flow chart of EMV compatible instructions (on-line part) ........................ 81. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v.

(8) List of Table Table 1. Symbol table of He’s protocol ....................................................................... 19 Table 2. Symbol table of Chen’s protocol .................................................................... 35 Table 3. Symbol table of the proposed scheme............................................................ 46 Table 4. Compare table ................................................................................................ 75 Table 5 EMV step cost time ......................................................................................... 82. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v.

(9) 1. Introduction Near Field Communication (NFC) technology on the mobile phone has gradually becomes mature. Therefore, in recent years, due to the gradually changing of people's consumption patterns, people start to replace the physical money transaction with the mobile payment, and replace the physical credit cards with non-contact payment, which then speeds up the transaction process. They also turn NFC mobile phones into virtual credit cards through the card simulation functions in the NFC technology [1][2][3][4][5][6][7][8]. However, the transactions through integrating credit card into. 政治大. the phone also bring many security issues; many scholars propose a method to put. 立. credit into the mobile phone in a secured manner. In addition, the privacy of. ‧ 國. 學. transaction behaviors are drawing more and more attention of the public because a great number of merchants would record the users’ consumption behaviors and then. ‧. recommend advertising contents to advertisers on the basis of the analysis of user. y. Nat. sit. behaviors. For the merchants, precise advertising is critical. But in the view of users,. n. al. er. io. it is much more like a pair of invisible eyes monitoring every movement of theirs’. As. i n U. v. a consequence, the anonymity function of mobile payment becomes more and more. Ch. engchi. underscored. The recently published Apple Pay [9] and Google Wallet [10] can replace the physical cards of users through the Token and thus allow the physical information of credit cards to be replaced by the Token. The Token transaction process can protect the user's information which is [11] proposed by two major international financial institutions, Master Card and VISA. The virtual credit cards allow users with no need to carry physical credit cards with them anymore. Any smart phone configured with WiFi, Bluetooth or NFC can serve as containers for virtual credit cards. Compared with the payment method of 8.

(10) traditional physical credit cards, virtual credit cards accelerate the settlement speed of users. As long as users get close to the Point of Sale (POS) machine, the action of consumption deductions will be implemented. Because of the Token, users don’t have to worry about the risks that merchants obtain their real card number. However, in order to maintain the security between users and merchants, there must be a card issuer to help the merchants to identify the correctness of the virtual credit cards of users. In this way, the places of consumption of users will be severely limited. Users can only perform payment action while the POS is connected to the network.. 政治大. However, under the traditional payment circumstances, merchants don’t necessarily. 立. need the network to confirm the payment action by linking to card issuer. Because the. ‧ 國. 學. physical credit card include the card number, card expiration date and last three digits , which can be utilized by the merchant to verify the correctness of the card. However,. ‧. when a user adopts the physical card for consumption, the merchant can also obtain. Nat. sit. y. the information of the physical card. If some malicious merchants conduct. n. al. er. io. consumption at other places by collecting users’ physical cards, it can lead to an unauthorized consumption.. Ch. engchi. i n U. v. As a result, in 2014, some cases came up that malicious attackers perform consumption by targeting small amount of off-line transactions. In these cases, malicious users use the expired credit card to consume. In these cases, malicious users can make consumption by using expired credit card.This could happen in real world since in Taiwan every transaction less than three thousands New Taiwan Dollars (NTDs) is regarded as an off-line transaction and it’s validity will not be verified by the card issuer during the transaction.Therefore, the merchants only can find out the unauthorized consumption by connecting the card issuer.. 9.

(11) As it’s not easy to control the risk management of off-line transactions, Europay, MasterCard, Visa (EMVCo) have specified three on-line transaction conditions to enforce EMV transaction must be on-line transaction [34]: 1. Exceeding the limit of cumulative consumption amount. 2. Exceeding the limit of consecutive consumption times. 3. Random inspection. However, the EMV risk management does not effectively prevent off-line double spending of the malicious users. Therefore, Balze et al. [12] proposed a new scheme by adding the some conditions, such as the limit of consumption amount and the life span into the user’s certificate, so as to reduce the. 政治大 proposed a new payment way to adopt transaction manner of one-way payword by 立. risks that malicious users cheat on off-line transactions. Rivest and Shamir et al. [13]. using the hash chain to prevent cheating on off-line transactions. But the hash chain. ‧ 國. 學. must be generated before the user make transactions, in which case, n is the length of. ‧. user’s hash chain which represent the consumable amount of n dollars. The merchant. sit. y. Nat. can ensure the users’ consumption amount by verifying whether it’s in the same. io. er. sequence of hash value. However, the merchant can also calculate user’s others hash values, which means the consumption information of the user is leaked to the. al. n. v i n merchant, so that the merchantC can have a chance toU h e n g c h i use the users’ payword to pay. Besides, it is a limitation that a payword can only be used with one merchant. Dai et. al. [14] proposed a new protocol to improve the payword consumption mechanism, so as to allow payword to be available at more merchants. For example, in their scheme, user’s certificate is required to have the information of the credit limit and the expired date. In this way, the user can use different parts of the same payword to make payment in different merchants. However, the merchant can only know the correctness of the payword, a malicious user still can successfully consume with merchants by sending the unregistered payword to the merchant, and the merchant can only find out that the payword is illegal when the merchant request payout to 10.

(12) payword issuer. Esmaeeli and Shajari [15] proposed the MVPayword method to allow payword to be available for consumption among multiple merchants, but under this protocol architecture, the transactions have been connecting with the payword issuer. Even though, it guarantees the validity of the users’ consumption payword. Although it can verify the validity of paywords a user consumed, but it has the disadvantage that their protocol does not support off-line spending. Fan et al. [16] proposed a double payword to confirm the identities of the user and the merchant, so as to increase the security for the user. Later, Fan et al. [17] also proposed an anonymous mechanism to. 政治大 anonymity, it greatly increased the amount of calculation to guarantee the correctness 立. ensure that the user can be anonymous during the consumption. In order to ensure. of the user identity. Therefore, the way of adopting a huge amount of calculation in. ‧ 國. 學. the transaction environment is not suitable for the application in the actual. ‧. transactions.. Nat. sit. y. However, Token technology is not unbreakable. For example, in 2016, the token of. n. al. er. io. Samsung [18] was cracked by a hacker, which resulted in leaking of users' card. i n U. v. information and forging credit card token for illegal consumption. Because the token. Ch. engchi. value of Samsung pay is not completely random but organized in regular manner, malicious users can crack the rules of the Token card numbers through collecting card numbers. In the light of Samsung issue, our protocol allows users to choose random number as the token value when the users apply to token server provider (TSP). So, it can avoid token be predictable. This thesis proposed a new off-line transaction protocol which not only can make sure keeping the user anonymous, but also prevent of the double spending attack. We use the SE to protect the classified information of the user and make sure no one can forge the signature in the transaction including the users. 11.

(13) In addition, the mobile payment protocol specified in the EMV must comply with the principle that the transaction shall be completed in 0.5 seconds. In order to proof this study’s running time can be under 0.5 second, we follow this protocol and program code. The running time will be discussed in chapter 7. This paper will introduce our new on-line and off-line transactions protocol, related architecture diagrams and transaction mechanism. The security that we can achieve will be covered at the end of the article.. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 12. i n U. v.

(14) 2. Background Knowledge 2.1 Near Field Communication (NFC) NFC (Near Field Communication) [19] is short distance transmission technology, and the NFC effective distance is about 10 centimeters. Compared with the traditional network transmission protocol, there is no need for NFC to worry about the man-in-the-middle attack during the communication of the user by intercepting and tampering the packet. Given the advantage of short distance for NFC, there is a. 政治大 by tampering the data and intending to make the NFC device unavailable to 立 certain difficulty for a malicious user to denial-of-service or man-in-the-middle attack. unscramble the message sent by a NFC mobile phone.. ‧ 國. 學. The safety of NFC mobile phones is very important. The malicious program infecting. ‧. the phone may allow malicious users to obtain sensitive information in the phone, so. Nat. sit. y. the NFC mobile phone must be configured with a security element to protect. n. al. er. io. confidential information of the phone from being tempered by external or malicious. i n U. v. programs if you want to use virtual credit card through the card simulation mode of NFC phone.. Ch. engchi. 2.2 Secure Element (SE) Under the existing SE mechanism [35], single SE can be cut into a number of different secure areas to support different Apps. The administrator for each secure area has a key to control the right of access to this area. Without the key, nobody is able to modify the confidential information in the SE. Through the calculation function of SE, we can allow the SE to be responsible for the encryption, decryption and data signature of confidential data [20]. 13.

(15) Our protocol uses the SE design of micro SD card. Compared with other two control modes of the SE: SIM card and built-in SE phones, the SE of the micro SD card does not need to access the SE content by obtaining additional authorization of TSM as well as via the operators. During the installation of App, the system will ask SD card to produce the security position of SE at the same time, and it’s also configured as that the SE can be only accessed by the key of Issuer. As discussed in the paper, if users can intercept or modify the information of card reader delivered between payment Apps and the stored after obtaining the Root access. 政治大. to mobile phones, the user will be able to make malicious modification on the. 立. transaction amount or other transaction attribute to achieve the double spending. ‧ 國. 學. attack[21]. Most payment Apps in the mobile nowadays have the SE to protect the sensitive data of users’ credit card and they can use SE to store cumulative amount of. ‧. transactions. But if the user can cheat on SE and set each transaction amount to 1 or. Nat. sit. y. other amount lower than the actual consumption amount, resulting in wrong records. al. er. io. of the transaction behaviors on the SE. Moreover, because the merchant cannot know. v. n. whether it’s the actual transaction amount of the user under the off-line mode, it. Ch. engchi. i n U. allows malicious users to perform the behaviors of double spending attack. This paper emphasized the method that we can ensure security of transactions through merchant must to verify transaction detail when transaction ending. Besides, sensitive transaction information and key can be stored through SE in order to ensure that the credit card of the user will not be used for consumption by the stealer when the cell phone information is stolen.. 2.3 EMV EMV [22] is the standard for smart payment card and POS terminals which accept 14.

(16) chip card and formulated by the international financial community. Currently, the standard is governed by the institution of EMVCo, which is mainly responsible for developing and maintaining the specifications, standards, and verification of EMV payment chip cards. The main standard is based on ISO/IEC 7816 and ISO/IEC 7816. Currently, standard EMV chip card include: VIS-Visa, M/Chip-MasterCard, AEIPS-American Express, UICS-China Union pay, etc.. 2.4 Token Payment. 政治大 The Token service providers established by the trusted third party, such as: VISA or 立. ‧ 國. 學. MasterCard. The application of the Token services can be made by the card Issuer of the user to Token service provider (TSP). After TSP receives the application, it will. ‧. convert the Personal Account Number (PAN) sent by Issuer into a random Number. sit. y. Nat. which called a Token, and the Token value converted by the TSP must be quite. io. er. different from the users’ PAN on the users’ credit card, so that no one can let reverse back the users’ PAN through the information on the Token. Besides, the Token value. al. n. v i n C h[23] to verify the correctness must go through Luhn Check Digit of the Token value. engchi U. During the transaction, the merchant can check the validity of the Token through the user certificate passed over by the user or by inspecting the Token. We can adopt the Token protection mechanism to achieve the anonymity of the users’ in the process of transaction.. 2.5 Off-line Payment In the existing credit card system, during the transaction of the users and the merchant, they need get reach to the card issuer so that issuer can help verify the users’ card. 15.

(17) Therefore, that payment where the verification by via the card issuer is required through the network is called the on-line payment. On the other hand, the user deals with merchants without via issuers verifying or other third parties is called the off-line transaction. The main feature of off-line payment [36] is the transaction without the investment of Issuers, and the users can deal the transaction with merchant directly. However, due to the lack of the verification steps for off-line payment, it is a very important step to confirm the identities of both parties as well as the transaction security between the merchant and users.. 2.6 Double-Spending. 立. 政治大. ‧ 國. 學. No issuers are involved to verify the transaction actions in the off-line systems, so the. ‧. malicious user can use the vulnerability, which means the malicious user can use the. sit. y. Nat. fake or expired card to deal with merchants. Due to merchants have no ability to. io. al. er. verify the user’s card by themselves; the malicious user can successfully cheat with. n. merchants in the off-line transaction. On the other words, the malicious user can use. Ch. engchi. the same money with the different merchants in. iv n the U off-line. transaction via the. vulnerability.. 2.7 Token Payment Users can send request to the TSP to convert the physical credit cards into virtual Token credit cards. The converted Token card number represents a credit card, and the user can use the Token to apply for a transaction to the merchant. The merchant sends the Token back to TSP through issuer's internal network after he receive the Token, the TSP will convert the Token into the information of physical credit card and then send the information to Issuer of the user to apply for the consumption. 16.

(18) After card issuer receives the consumption application, he can perform the action of on-line wiping of credit card, and then perform the action of transferring the money to Issuer account of the merchant, constituting the overall process of the Token payment show as Figure 1.. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. Figure 1. Overall process of the Token payment [11]. 17.

(19) 3. Related Works In this chapter, we will discuss He et al.’s [33] off-line payment protocol in session 3.1. He et al. proposed a protocol which is not only allows the user to deal with merchants in off-line mode, but is also compatible with EVM standard. And the other we will discuss in session 3.2 is Chen et al.’s [26] protocol which can allow the user can be anonymous and keep the user’s information confidential.. 3.1 He et al.’s EMV-based Offline Payment with Mutual Authentication. 政治大. In 2014, Yang et al. [24] point out the transaction problems in the EMV, including:. 立. cards fail to identify the card readers, unencrypted connection; merchants cannot. ‧ 國. 學. confirm the validity of the credit cards immediately in off-line mode, etc. However, the protocol which proposed by Yang et al. may cause the problems of credit. ‧. er. io. sit. Nat. behaviors of double spending by malicious users.. y. expansion after performing off-line transaction for many times, which can lead to the. In order to improve the method proposed by Yang et al. in 2014, He et al. [33]. al. n. v i n proposed an EMV based secureCprotocol which improves the security of the method hengchi U proposed by He et al.. Under this protocol, off-line transaction certificates applied by users contain two hash chains, which include both the Payword value of user consumption and the Payword value of merchant identify. Through the authorization of Issuer, users can generate the off-line certificates for the amount of the transaction before each off-line transaction; merchants can confirm the correctness of the user payments after receipt of the Paywords and off-line certificates. The protocol symbols show as table 1. 18.

(20) Table 1. Symbol table of He’s protocol[33] Target’s certificate which is issued by Publisher include. publisher. Cert target. target’s Public and Private key pairs Cert off. Certificate for Off-line transaction. PK A. The public key of A. SK A. The private key of A. Kencemv. The symmetric key between card and card Issuer used for. 政治encrypting 大. 立The symmetric key between card and Issuer used for. Kmacemv. ‧ 國. 學. ‧. y. The session key between cell phone and merchant. sit. io. K iss. transaction message which give to Issuer.. Nat. TK. The symmetric key between Issuer for encrypting off-line. The key only own by Issuer which used for encrypting. er. Kβ. computing message authentication code. n. aspecific i v number to create the l C serial number and random n h e n secret i Uin hash chain g c hvalue. Ekey (X). Encrypt function that uses key to encrypt message X. Dkey (X). Decrypt function that uses key to decrypt message X. MACKmacemv (X). Computing X’s message authentication code by key Kmacemv in EMV protocol. HMACkey (X). Hash function that uses key to hash message X. h(X). Hash function that to hash message X. n. Amount of transaction in off-line mode, also means computable times in hash chain 19.

(21) t. The maximum number of transactions. m. The number of authorized merchants for off-line transaction. wn. The first value in hash chain used for payment. w0. The last value in hash chain used for payment. s0. The first value in hash chain used for record by user. sn. The last value in hash chain used for record by user. STable. The table which record wn , s0 hold by Issuer. SNi. The ith serial number. Ri. number 政 The治ith random 大 The information of the off-line credit card. 立. R lim. sit. y. A set include all authorized merchants which can dealing in. v. Identity of Merchant i. n. al. er. off-line mode. io. IDMi. S={S0, ..., Sn}. Nat. M. W={w0, ..., wn}. ‧. S. ‧ 國. W. The content include manage amount of transaction and limit. 學. Lim. i n U. counter. CThe h eamount counter in off-line i n g cof htransaction. φ. The signature on w0 signed by issuer means the amount for off-line transaction endorsed by the issuer. 𝑙. The number of the hash iterations. end_time. The maximum off-line transaction time set by merchant. Issuer. The identity of Issuer. PAN. Primary Account Number. ET. Expiry Time. Current Time. transaction time 20.

(22) b. The amount that has been used. c. The amount of the transaction. u. The number of the last transaction. 𝑣. The number of the current transaction, v = u+1. β. The message for the card issuer to verify the validity of the off-line transaction. μ. The message for the merchant to verify the validity of the off-line transaction. 立. Revisit of He et al.’s Protocol. 學. ‧ 國. 3.1.1. 政治大. This protocol is divided into five stages: 1. Mutual authentication stage between users. ‧. and merchants 2. Function selection stage 3. Off-line certificate application and authorization stage 4. Off-line/on-line transaction stage 5.Merchant payout request. er. io. sit. y. Nat. stage. al. v i n C h in the EPMARUby Hong et al. [32], which can protocol is based on the EMV proposed engchi n. The dotted box (ie., -..-..-) in the Figure 3, 4 is an additional part of this protocol. This. increase its off-line security in the transaction part of users and merchants. In the transaction parts between mobile phones and the merchant, we will all use the session key TK generated in the Users’ stage for encryption and communication. Stage 1 and 2 of this protocol are all the same with the EPMAR of Hong et al. [32], so no more discussions will be made on that. Stage 1 is for users and the merchant to verify status of both parties by exchanging certificate; stage 2 is feature selection stage, which will confirm whether the user has 21.

(23) off-line certificates, and it will enter the transaction stage if the user has it; stage 3 off-line certificate application stage, the user will apply for off-line transaction certificates to Issuer in this stage and hand it over to the next stage; stage 4 is for transaction, the transaction is off-line at the beginning, and the transaction info will be delivered to Issuer if the merchant support on-line transaction; stage 5 is for the payout request of the merchant The protocol flow chat show as figure 2.. 立. 政治大. al. n. Off-line Certificate Application. Ch. engchi. er. io. sit. y. ‧. ‧ 國. 學. Nat. 3.1.3.1. Figure 2. Flow of the protocol. i n U. v. In stage 3 for off-line certificate application, the user will perform the following steps: Step 1. Merchants request users’ NFC mobile phone to present off-line certificates Step 2. If the users’ mobile phone does not have off-line certificates (2a-1) The phone applies for the required off-line transaction certificates o to Issuer. (2a-2) Issuer produces off-line certificates. After that the users’ NFC mobile phone receives that, it will be stored in the SE of the phone. If the phone has off-line certificates 22.

(24) (2b) The mobile phone sends the off-line certificates to the merchant Figure 3 is the off-line certificate application during the transaction between users and the merchant; the reserve field means the additional information in the protocol that is compatible with EMV instruction; the blue part is additional step based on EPMAR.. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 23. i n U. v.

(25) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. Figure 3. Contents of the off-line certificate application 24.

(26) 1. When user receives the GENERATE AC instruction containing parameter OCRC (off-line Certificate Request Cryptogram) and decrypts the content with TK, it will obtain the transaction number ATC,Datacdol1 and the random number R m for this transaction, and it uses the shared key with Issuer to produce a message verification code. 2. The user will encrypt OCRC, ATC, AC by session key TK and send to merchants 3. After the merchant received cipher text form the above step then decrypted by using the TK, it passes Datacdol1,the longest time (end_time) and the random number. 政治大. to Issuer for the off-line environment, and let Issuer produce the certificate according. 立. to the information. ‧ 國. 學. 4. When Issuer receives the OCRC request, it can use its shared key with the user to. ‧. verify the correctness of the message delivered by the merchant. If it is a wrong. sit. y. Nat. message, it will set the ARC (Authorization Response Code) as failure, otherwise it. io. al. n. relevant information:. er. will produce the off-line transaction certificates, quota segmentation and other. Ch. engchi. i n U. v. (1) Produce two secret factors {Wn , S0 } where Wn representing the quota and the S0 representing the merchant (2) Separately calculate the hash chain of each secret factor W = {wi |wi = h(wi−1 ), where i ∈ {1 … n} } S = {si |si = h(si+1 ), where i ∈ {0 … t − 1} (3) Set M as the set of all identities of authorized merchants. (4) Produce a key K β with which Issuer can verify transaction information, current 25.

(27) quota of the user b = 0 (5) Use its private key to sign the last item of the quota hash items, φ = 𝐸𝑆𝐾𝑖𝑠𝑠 (𝑤0 ), so that the merchant can confirm the transaction in the future (6) Use the public key of the credit card PK emv to produce the off-line transaction information Lim, Lim = EPKemv {K β , wn , SNw , s0 , SNs , b, φ, R lim }. It contains the key K β which share on user and Issuer, secret quota factor, usage quota and random number R lim of the user and Issuer. 政治大 will produce the off-line certificate, which contains the name of Issuer, credit card 立. (7) According to the EMV standard and the end_time delivered by merchants, Issuer. ‧ 國. 學. account of the user PAN, certificate expiration date, limit of consumption quota n, all authorized merchants M.. ‧. And it will use with the shared key with the user to deliver the certificate and Lim to. io. sit. y. Nat. the merchant. n. al. er. 5. If the ARC replies that the merchant fails to receive from Issuer, it is deemed as termination. of. the. Ch. transaction,. otherwise,. engchi. iv will n U. it. adopt. EXTERNAL. AUTHEENTICATION to deliver the information that is sent by Issuer back to the user. The user performs the following steps after receiving the certificate information from the merchant: (1) Use the shared key with Issuer to decrypt the cipher text and confirm whether its MAC and verification if certificates are correct or not. (2) If it’s correct, just put the Dataemv in certificate and stored. 26.

(28) (3) Use the private key of the credit card SK emv to decrypt Lim and put it into the SE. After the mobile phone receives Lim, it will directly be sent to the SE for decryption. There the role of mobile phone is a transshipment part between the merchant and the SE (4) Decrypt φ, conduct n times hash operations, and then verify whether wn is equal to w0 , if it succeeds, the counter in the SE should be set to 0, and if the counter is n, it represents that the consumption amount is full, and then set the ACK as success. (5) Send ACK to the merchant.. 政治大 verification fails, we must reapply the certificate. 立. 6. If the ACK that the merchant receive is failure, that represents the certificate. ‧ 國. 學. 3.1.3.2. Off-line/On-line Transaction Stage. ‧. In this stage, the user will send certificate to the merchant. The merchants will decide to do transaction on-line or off-line, as shown in Figure 4 and 5.. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. Figure 4. Flow chart of the off-line transaction. 27.

(29) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. Figure 5. Contents of the transaction step 28.

(30) 7. When the user receives GEMERATE AC instruction delivered by the merchant, it will use session key TK to decrypt the information and display it on the users’ device, and let the user to make verification on the correctness of the transaction information. If it’s correct, it will conduct the following steps in accordance with the EMV payment protocol. (1) Generate a random number R m and generate MAC with the transaction serial number ATC Kmacemv , transaction information Data𝑐𝑑𝑜𝑙1, random number R m as AC1 by 𝐾𝑚𝑎𝑐𝑒𝑚𝑣 . In short, compute AC1 = MACKmacemv ( Datacdol1 , 𝐴𝑇𝐶, R m ).. 政治大. (2) Compute the hash value by hashing with AC1, the random number R P , Req which. 立. is type of transaction, R m , Data𝑐𝑑𝑜𝑙1 and ATC . In short, compute H(R P , Req,. ‧ 國. 學. AC1, R m , Data𝑐𝑑𝑜𝑙1, ATC).. ‧. (3) Use the private key of EMV card 𝑆𝐾𝑒𝑚𝑣 to encrypt the above information and. sit. y. Nat. hash values as SDAD (Signed Dynamic Application Data). In short, compute SDAD. io. n. al. er. = ESKemv (R P , Req, AC1, h(R P , Req, AC1, R m , Datacdol1 , ATC)). i n U. v. (4)See whether the ID delivered by the merchant is included in Issuer verification list M. Ch. engchi. (5) Adopt the used quota b to calculate the used hash value wb = hn−b (wn ) and compute the amount of the transaction c by wb+c = hc (wb ). (6) Calculate the merchant code sv = h(su ), and if it’s the first consumption then it should be: u = 0, v = 1. All the transaction after it will generate the unique number value sv that represents the merchant. In the transfer of transaction information, the merchants won’t know the unique number, only the user and Issuer know it. (7) Add this transaction amount c to the amount b that has been consumed, and update 29.

(31) the position used in the hash chain (8) Add c to the counter to update the consumption amount (9) Use off-line verification key K β to encrypt with merchant identify hash value sv , 𝑤𝑛 ’s serial number 𝑆𝑁𝑤 , 𝑠0 ’s serial number 𝑆𝑁𝑠 and random number R lim as verification message β which is given to the Issuer. β = 𝐸𝐾β (sv , 𝑆𝑁𝑤 , 𝑆𝑁𝑠 , R lim ). (10) Use the private key of EMV credit card SK emv to sign with the verification message β, the quota endorsed by issuer φ, used hash quota wb , hash value of. 政治大 counter) and merchant identity ID as signature μ. μ = 𝐸 立. payment amount wb+c , current transaction amount c, off-line quota counter (ie., SKemv (β,. Mg. ‧ 國. 學. counter, IDMg ). φ, wb , wb+c ,. 8. Encrypt Req, ATC, SDAD, β and μ by session key TK then send to the merchant.. ‧. And then keep the additional message into the reserved fields of the GENERATE AC.. er. io. sit. y. Nat. al. v i n C h Req, ATC, SDAD, the cipher text form the user and get e n g c h i U β and μ by using TK. Then n. After the merchant receives information send by the user, the merchant can decrypt. the merchant can decrypt μ and get β, φ, wb , wb+c , counter, IDMg by public key of issuer PK emv .After that, the merchant can follow the below steps to verify whether the users’ information is correct: (1) Use the public key of the credit card PK emv to verify whether SDAD is correct or not. (2) Verify whether IDMg is correct or not (3) Check whether off-line certificates expires 30.

(32) (4) Check whether the counter is less than or equal to n in off-line certificates (5) Verify the correctness of wb by checking whether hc (wb )is equal to wb+c To complete the transaction if the above steps are all correct. 3.1.3.3 Merchant Payout Request Stage In this stage, the merchant deliver the parameters obtained in the transaction stage back to the users’ Issuer and apply for the payout request of the transaction, as shown in Figure 6 and 7.. 立. 政治大. ‧. ‧ 國. 學. Figure 6. Flow chart of the merchant payout request stage. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. Figure 7. Contents of the merchant payout request stage. 31.

(33) The merchant sends the β, μ back to Issuer for verification, and Issuer can verify the content after encrypting the β and μ by K β , PK emv . Issuer calculates the value in the off-line certificate, β in the wn and the random number R lim sent by the merchant, so as to confirm whether the merchant name is in the list M, and will check whether the user consumption balance exceeds n. If all the above is correct, Issuer will transfer money to the merchant Issuer account.. 3.1.4. Security Features. 政治大. He et al. [33] claimed that this protocol would be able to achieve the following. 立. security:. ‧ 國. 學. 1.. Verifiability: In the transaction stage and payout request stage, the merchant and. Issuer can verify all messages to ensure the correctness of the transaction. ‧. 2.. Resistance to forgery: In the application stage, the users’ hash chains will all be. y. Nat. io. sit. signed with Issuer's private key to ensure that they are the hash chains sent by Issuer;. n. al. er. when the user send information to the merchant in the transaction stage, they are all. Ch. i n U. v. signed by the private key of the credit card. After the merchant confirms it, they will. engchi. request the payout to Issuer. If the user uses fake amount, it will be found. 3.. Resistance to tampering: In the application stage, the message sent by Issuer and. the user will all use a shared key and a public-key of credit card for encryption and protection; the hash chain will be signed by Issuer’s private key. Fake hash chain cannot be verified and will fail; the verification information given to the merchant should be signed by a private key of the credit card, and the private key is stored in the SE, if the users’ phone is infected with malicious software, the malicious software cannot read the content in the SE. 32.

(34) 4. Resistance to replay attack: Issuer will put a random number in the protocol, and. after receipt of the payout request, Issuer will verify whether these random number is the same as the random number sent at the beginning. 5. Non-repudiation: In the transaction stage, the user will use the private key to sign the information that is sent to the merchant to ensure that it is given out by the user; in the payout request stage, the corresponding hash value of a unknown merchant will be put into the verification message given to Issuer to confirm whether the quota is used by this merchant. 6.. 政治大. Resistance to repeated consumption: Set up a rule in the SE of the users’ mobile. 立. phone so that the counter value is forced to increase after each transaction, and this. ‧ 國. 學. counter value must be lower than the transaction quota that the user applies for. If the. Protocol Discussion. sit. y. Nat. 3.1.5. ‧. user reuses the quota hash value, the counter value will still be forced to increase.. n. al. er. io. In the protocol proposed by He et al. [33], the off-line certificate that the user apply. i n U. v. for will be passed over from the merchant, to the user and finally to the SE. If the. Ch. engchi. merchant modifies users’ off-line certificates, the user cannot know whether the problem is from Issuer or the merchant even after the certificate is verified through the signature of Issuer. In addition, the valid time of the off-line certificate is also determined by the merchant, so if the merchant will limit the valid time to a few minutes, this certificate will not be able to play the proper function of off-line certificate, instead, it will have to repeat the action of applying on-line certificate again then again. Moreover, malicious users also have the opportunity to modify the information during the information storage. As the public and private keys of the virtual credit card are 33.

(35) not just produced and used by a SE, the users have the opportunity to obtain credit cards and private key, so that SE information may has the risks of being modified, for example, after receiving Lim, SE will store the limit value b of the users’ credit card. At this moment, if someone uses private key of the credit card to modify Lim and also modify the limit of b to be higher and then put the modified Lim back to SE. SE will just store it without being able to distinguish whether the Lim has been modified or not. Besides, the user can also know the content value of the hash chain. In addition, in the process of consumption, as the merchant can only judge the. 政治大. correctness of the hash chain and the SE can only judge the consumption amount, so. 立. if the user adopts the used hash chain to do the verification with the merchant, the. ‧ 國. 學. merchant will not be able to detect that hash chain has been consumed and will receive it, thus causing the double spending problem. If the user modifies the. ‧. Datacdol consumption amount to 1, the consumption amount can thus be modified,. Nat. sit. y. and the SE will be cheated on as if the transaction amount is 1. At this moment, the. n. al. er. io. user can pass the transaction if he sends the correct length of the known hash chain content back to the merchant.. 3.2 Chen’s. Ch. Improvement. hi. e. i n U. gc on n NFC-Based. v. Anonymous. Mobile. Payment Protocol This protocol introduced by Chen [26] is based on NFC-based Anonymous Mobile Payment Protocol propose in 2014 by Luo et al.[25], which improves the problem that the public key system and key pairs in the protocol are mixed up when used in the part of encryption and digital signature, leading to the risk of forged signature and reducing the transmission data. This protocol separates public key and symmetric key so that the public key is used only for digital signatures and the symmetric key is used 34.

(36) for the encryption and decryption to prevent the tampering of information; it also provides anonymity when users can do transactions without presenting their real information. In addition, it is compatible with EMV protocol. The protocol symbols show as table 2. Table 2. Symbol table of Chen’s protocol[26] pw. The password that user sets when user apply for physical account to Issuer. VA-request. 治政 which 大 from user to Issuer is transported. The virtual account applying request. 立. VTA-request. The. account. ‧ 國. 學. ‧. card request which is transported from user to TSM. y. sit. The virtual credit card update request. n. al. er. io. AIDU. transaction. registration and issuing a virtual credit. Nat. Update-request. virtual. which is transported from user to TSM. v i n The anonymous virtual account which is Ch engchi U generated by Issuer. TIDU. The. anonymous. virtual. transaction. account which is generated by user and register it to TSM A_Extime. The expiry date of account A. A_Limit. The credit limit of account A. Credit_INFO. The corresponding information about virtual credit card 35.

(37) TS. Timestamp. Nj. The j-th random number whose value equals to the value of Nj-1 + 1. TicketB,TSM. The authentication certification which is generated by Issuer and verified by TSM. H(). Hash function. Ek(m). Encryption function which uses the session key K to encrypt a message m. Sig SKA (m). 立. ‧ 國. y. sit. io. A prime whose length is 1024-bit. al. n. x. The generator of Zp*. er. p. The generator of Zp*. Nat. h. a Diffie-Hellman key. ‧. g. The cipher text which is used to generate. 學. C. 治signature which uses A’s private key 政 The 大 to encrypt message m. v i n Ch e n ggenerate c h i aUDiffie-Hellman session key. The random number which is used to. y. The random number which is used to generate a Diffie-Hellman key. XU. The random number which is used to generate a Diffie-Hellman key and generated by user. YTSM. The random number which is used to generate a Diffie-Hellman key and generated by TSM 36.

(38) Lifetime. The expiry date of Ticket. k’. The value equals to gxy mod p. K. The session key which is generated by H(k’). 3.2.1. Initialization Stage. In the initial stage, TSM, the user and Issuer all have their own identifications IDU , IDTSM , IDB ; TSM and Issuer have their own public/private key pair PK B , SK B ,. 政治大. PK TSM , SK TSM ; moreover, the user and Issuer has the password of the users’ physical. 立. account pw; the users’ account and password is stored in the SE of the users’ mobile. ‧ 國. 學. phone, and the TSM and Issuer have the session key K B,TSM .. ‧. We assume that the TSM and Issuer are semi-honest, namely that, the TSM and Issuer. sit. y. Nat. will both follow the protocol, but they will also try to obtain the users’ information.. io. n. al. er. Figure 8 shows the information owned by each role.. Ch. engchi. i n U. v. Figure 8. Information owned by each part on Initial stage. 3.2.2. Applying for Virtual Accounts Stage. In this stage, the user will apply for the virtual account AIDU to Issuer and obtain the TSM verification Ticket B,TSM , which is used in the stage when the user apply for virtual transaction accounts to TSM, as shown in Figure 9.. 37.

(39) 政治大. Figure 9. Flow of applying for virtual accounts stage. 立. 1. IDU → IDB : (IDU , IDTSM , VA − request). ‧ 國. 學. The user will send the user’s information IDU , IDTSM and request of applying for. ‧. virtual accounts VA − request to Issuer. sit. y. Nat. 2. IDB → IDU :(C, g, h, p, Sig SKB (C, g, h, p)). er. io. Issuer will produce the session key after it receives the users’ request by adopting the. n. al. i n U. v. Diffie-Hellman key exchange. Issuer selects the random number xZp* first and then x. Ch. engchi. calculate the cipher text C= g hpw mod p, and after that, it produces the cipher text and parameter signature Sig SKB (C, g, h, p) and send the parameter and signature to the user 3. IDU : (y, K) The user selects a random number yZp* and decrypt C, then he can calculate k’= gxy mod p, and at last get the session key K by calculating the hash K=H (k’) 4. IDU → IDB : (IDU , IDB , N1 , TS1 , Y). 38.

(40) The user will calculate the parameter Y= gy mod p and use session key to encrypt the cipher text EK (IDU||IDB||N1||TS1||H (IDU||IDB||N1||TS1)), then pass it to Issuer 5. IDB : (K,AIDU , AIDU Extime , AIDU Limit , , Ticket B,TSM After Issuer receives the Y, it can calculate the session key K and verify whether the hash parameters is correct. If it’s correct, then the cipher text should be decrypted by using K. Issuer will produce virtual user account AIDU , AID expiration date (AIDU_Extime), AID limit (AIDU_Limit) , initial session key between the user and the TSM KU, TSM, and the TicketB, TSM verified by the TSM. Meanwhile, TicketB, TSM contains. 政治大. 立. (IDB||AIDU||AIDU_Extime||AIDU_Limit||TS2||Lifetime||KU,TSM||(IDB||AIDU||AIDU_Exti. ‧ 國. 學. me||AIDU_Limit||TS2||Lifetime||KU, TSM)).. ‧. 6. IDB → IDU: (IDB, AIDU, AIDU_Extime, AIDU_Limit, TicketB,TSM, KU,TSM)). Nat. sit. n. al. er. io. session key K. y. Issuer will deliver the parameter generated in the above steps to the user through the. Ch. 7. IDU → SE: (KU,TSM, AIDU_Extime, AIDU_Limit). engchi. i n U. v. The user sends all information to SE then store. After receiving and decrypting the cipher text, the user can obtain related information of AID, as well as Ticket. 3.2.3. Applying for Virtual Transaction Accounts and Issuing. Virtual Credit Cards Stage In this stage, the user will apply for the virtual transaction account TID and virtual credit card to TSM by adopting the use AID information and Ticket that he applies for 39.

(41) to Issuer the above steps. First, the user will encrypt the AID information by using the session key KU, TSM given by Issuer, and TSM can decrypt the Ticket content and obtain the session key to the user by using the communications key of the KU, TSM after receiving the Ticket delivered by the user. Then, TSM can accept the users’ application for the virtual transaction account, the user will obtained relevant information of the virtual transaction account TID after this step. As shown in Figure 10.. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. Figure 10. Flow of Applying for virtual transaction accounts 1. IDU → IDTSM: (IDB, AIDU, TIDU, g XU , TicketB,TSM, VTA-request) The user produces the TIDU and the random number XU, and calculates the hash value of TicketB,. TSM. for verification. And then TSM can use the communications key. KU, TSM to encrypt the application requirements, Issuer name, AID, TID, XU to cipher 40.

(42) text EKU,TSM (VTA-request||IDB||AIDU||TIDU||g XU ||H (TicketB,TSM)) and send to TSM. 2. IDTSM: (KU,TSM, IDB, AIDU, TIDU) TSM obtains the TicketB, TSM through the decryption of session key of Issuer, then TSM will get the session key to the user KU, TSM. After that, it can use the key to decrypt the users’ cipher text, then TSM will check whether the Ticket t is consistent with the content of cipher text. If it’s the same, TSM can confirm Ticket is sent by Issuer. TSM will record TID and AID into the TSM database.. 政治大. 3. IDTSM: (YTSM, KTSM’U’, TIDU_Extime, TIDU_Limit, Credit_INFO). 立. TSM produces Diffie-Hellman random number YTSM and calculates the new session. ‧ 國. 學. key KTSM’,U’= H(g XU YTSM mod p). TSM produces the information of TID, including TID expiration date(TIDU_Extime), TID limit value(TIDU_Limit), and generate. ‧. information of the virtual credit card Credit_INFO, and TSM will record TID and. Nat. io. sit. y. PAN of the virtual credit card into the TSM database.. al. n. TSM. uses. new. er. 4. IDTSM → IDU: (g YTSM , TIDU_Extime, TIDU_Limit, Credit_INFO). v i n C h key to U produce session engchi. cipher. text. EKTSM′U′ (IDTSM||AIDU||TIDU||TIDU_Extime||TIDU_Limit|| g YTSM ||Credit_INFO||TS3|| Sig SKTSM (IDTSM||AIDU||TIDU||TIDU_Extime||TIDU_Limit|| g YTSM ||Credit_INFO||TS3)), and sends the cipher text and parameter g YTSM to the user. 5. IDU → SE: (KTSM’U’, TIDU_Extime, TIDU_Limit, Credit_INFO) After the user receives g YTSM , he will calculate the session key KTSM’U’, and then decrypt the cipher text sent by TSM. At this point, the user can get TID and information of the virtual credit card.. 41.

(43) 3.2.4. Updating Virtual Credit Cards and Optional Virtual. Accounts Stage In this stage, under the circumstances that the users’ virtual credit card expires or reaches the limit, he can contact TSM for updating the virtual credit card and virtual account. In this step, the user will use session key which generated during the Diffie-Hellman process with TSM previously, as shown in Figure 11.. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. Figure 11. Flow of Updating virtual credit cards and optional virtual accounts 1. IDU: (XU´, TIDU´) The user produces a new random number XU′, and produces a new TID. 2. IDU → IDTSM: (Update-request, TIDU´, g XU ′) The user uses the session key to produce cipher text and then encryptthe update 42.

(44) request, original TID, new TID to ETSM′U′ (Update-request||g XU ′ ||TIDU|| (TIDU´) ||H (Update-request||g XU ′||TIDU|| (TIDU´))) and send to TSM with the parameter. 3. IDTSM: (YTSM´, KTSM´Ú´´, TIDU_Extime´, TIDU_Limit´, Credit_INFO') TSM produces a new random number YTSM′ and calculates a new session key KTSM´Ú´´= H (g XU ′YTSM ′ mod p) then decrypts the user' new cipher text to obtain the new TID value, and sees whether it’s correct by comparing it with the old TID. If it's correct, TSM will update the TID value in the database into the new one, and produce the new TID information, including limit value, expiration date, etc. 4. IDTSM → IDU: (𝑔𝑌𝑇𝑆𝑀. 政治大 ′, Credit_INFO´, TID _Extime´, TID _Limit´) 立 U. U. ‧ 國. 學. TSM will encrypt information of the new TID 𝐸𝐾𝑇𝑆𝑀"𝑈" (IDTSM||. ‧. AIDU||(TIDU´||TIDU_Extime´||TIDU_Limit´)|| 𝑔𝑌𝑇𝑆𝑀 ′ ||Credit_INFO´|| 𝑆𝑖𝑔𝑆𝐾𝑇𝑆𝑀 (IDTSM||. er. io. al. sit. Nat. session key and send to the user with the parameter 𝑔𝑌𝑇𝑆𝑀 ′ .. y. AIDU||(TIDU´||TIDU_Extime´||TIDU_Limit´)|| 𝑔𝑌𝑇𝑆𝑀 ′ ||Credit_INFO´)) by the new. n. 5. IDU: (𝑔𝑌𝑇𝑆𝑀 ′, Credit_INFO´, TIDU_Extime´, TIDU_Limit´). Ch. engchi. i n U. v. After the user receives the information, he can calculate new session key KTSM´Ú´ánd obtain the information of new TID. 6. IDU → SE: (KTSM´Ú´´, Credit_INFO´, TIDU_Extime´, TIDU_Limit´) The user sends the new session key KTSM′′U′′, and the new TID information to SE then SE will store those information.. 3.2.5 1.. Security Features. Anonymity: The user will only deliver real information during the application for 43.

(45) the virtual credit card from Issuer, and user used AID for application during the stage of applying for the virtual transaction account. Therefore, in this protocol, Issuer will only know the relationship between users’ true identity and AID, and TSM will only know the relationship between AID and TID. Among all the parts, no one can know the all the identities of the user. 2.. Unlinkability: As long as the user updates the virtual credit card and TID, so the. merchant cannot trace the user behavior by using different TID for a same user. 3.. Non-repudiation: All of the information delivered in this protocol adopts the. 政治大. encryption of the Diffie-Hellman key, and signature part also uses the private key, so. 立. the information in all stages could not be copied.. ‧ 國. 學. 4.. Resistance to replay attack: In this protocol used timestamp in each stage to. ‧. confirm the delivery order of the information, so it will be discovered if an old. y. sit. n. al. er. Integrity: In this protocol, every message sends with hash value in each. io. 5.. Nat. message is delivered.. i n U. v. transmission step to ensure the receiving terminal can verify the integrity of the information. 6.. Ch. engchi. Data confidentiality: All the information communication adopts the encryption of. Diffie-Hellman key or the symmetric key, so the information delivery is confidential in each stage. 44.

(46) 4. Architecture of the Proposed Scheme This protocol adds off-line transaction mechanism based on the Chen [26] protocol which can safely and efficiently perform transactions using virtual credit cards. This protocol architecture is mainly divided into three stages: 1. Application for virtual credit cards and certificate issuing stage. 2. Consumption stage. 3. Payout request stage.. 政治大. 立. ‧ 國. 學. The parts in this protocol include Issuer, TSP, User, SE, acquire and merchant, with that functions shown as follows:. ‧. Issuer: Holding Users’ physical accounts and related information, and is taking. y. Nat. n. al. Ch. er. io. contacting TSP to issue User’s virtual credit cards.. sit. charge of receiving and reviewing User application for virtual credit cards, as well as. i n U. v. TSP (Token Server Provider): Responsible for receiving the application. engchi. requirements of virtual credit cards delivered by Issuer, managing virtual credit cards of User, issuing off-line certificates, as well as connection confirmation with Users’ mobile phone. User: The owner of the mobile phone, who provides SE authorization to TSP and makes TSP can connects to SE, SE: Being independent of Users’ mobile phones, it can sign signature and other functional calculation.. 45.

(47) Acquiring Issuer (Acquire): Merchant’s bank, receiving the transaction information from the merchant, the acquire requests a payout to Issuer through the existing internal network between Issuers. Merchant: Deploy the Point of Sale (POS) and send the information of transaction then verify the correctness of the transaction. In this protocol, the merchant is free to switch between off-line or on-line transaction modes. During each on-line transaction, Issuer will update Users’ credit card, so User can use different virtual credit card to deal with the merchants in the on-line mode.. 政治大 For this the architecture, in the process of transaction, User produces block after each 立. ‧ 國. 學. transaction, so the transaction chin of User after going through multiple transactions is called transaction block chain (TBC).. ‧. io. sit. y. Nat. 4.1 Initialization Stage. n. al. er. Users’ mobile phone must provide SE API, and User needs to provide the. Ch. i n U. v. authorization of this system to access the block of the SE. At the beginning of the. engchi. transactions, Issuer and each TSP has a session key K I,TSP to encrypt the communication between Issuer and each TSP. In addition, User and Issuer both know the password of Users’ physical account pw. Issuer and the TSP have their respective public-private key pairs PK I , SK I , PK TSP , SK TSP . The protocol symbols show as table 3.. Table 3. Symbol table of the proposed scheme. 46.

(48) pw. The password that user sets when user apply for physical account to Issuer. AID-request. The virtual account applying request which is transported from user to Issuer. TID-request. The virtual transaction account registration and issuing a virtual credit card request which is transported from user to TSP. AIDU. 立. 治anonymous virtual account which is 政 The 大 generated by Issuer The anonymous virtual transaction. ‧ 國. 學. TIDU. account which is generated by user and. ‧. register it to TSP The expiry date of account A. A_Limit. The credit limit of account A. al. er. io. sit. y. Nat. A_Extime. The corresponding information about. n. Credit_INFO. Ch. engchi. iv n Uvirtual credit card. TS. Timestamp. N. Random number. TicketI,TSP. The authentication certification which is generated by Issuer and verified by TSP. H(). Hash function. 𝐶𝑒𝑟𝑡𝑥. X’s certification. Ek(m). Encryption function which uses the session key K to encrypt a message m 47.

(49) Sig SKA (m). The signature which uses A’s private key to encrypt message m. C. The cipher text which is used to generate a Diffie-Hellman key. g. The generator of Zp*. h. The generator of Zp*. p. A prime whose length is 1024-bit. x. The random number which is used to. y. generate a Diffie-Hellman session key 政治大 The random number which is used to. 立. ‧ 國. 學. generate a Diffie-Hellman key. XU. The random number which is used to. ‧. generate a Diffie-Hellman key and. sit. y. Nat. generated by user The random number which is used to. io. iv n Ugenerated by TSP. generate a Diffie-Hellman key and. n. al. er. YTSM. Ch. engchi. Lifetime. The expiry date of Ticket. k’. The value equals to gxy mod p. K. The session key which is generated by H(k’). 48.

(50) 4.2 Application for Virtual Credit Cards and Certificate Issuing Stage In this stage, User will conduct the services in applying for virtual credit cards to Issuer and the TSP that User chooses. According to the goal in this stage, User will obtain the AID form Issuer and the TID and information of virtual credit cards form TSP. So, this stage can be subdivided into two stages, respectively: 1. User applying for AID. 立. 政治大. 2. User applying for TID and virtual credit cards. ‧ 國. Applying for AID Stage. User → Issuer: (𝐼𝐷𝑈 , 𝐼𝐷𝑇𝑆𝑃 , AID - request). ‧. 1.. 學. 4.2.1. Nat. sit. y. User delivers user information 𝐼𝐷𝑈 , TSP information 𝐼𝐷𝑇𝑆𝑃 and applying request of. n. al. er. io. virtual account (AID) to Issuer. 2.. 𝑥 𝑝𝑤. Issuer: (C= 𝑔 ℎ. mod p). Ch. engchi. i n U. v. Issuer produces session key immediately after receiving the application delivered by User, and this session key is generated by using Diffie -Hellman key exchange. Issuer chooses a random number x  𝑍𝑃∗ and then produce cipher text C = 𝑔 𝑥 ℎ𝑝𝑤 mod p. The cipher text in this step ℎ𝑝𝑤 adopts the password pw which is password of Users’ physical account only known by both Issuer and users.. 49.

(51) 3.. Issuer → User: (C, 𝑔, ℎ, p). Issuer sends the cipher text and parameters such as C, 𝑔, ℎ and p to User. 4.. User: (y  𝑍𝑃∗ , 𝑘 ′ = 𝑔 𝑥𝑦 , K=H (𝑘 ′ ), Y= 𝑔 𝑦 , 𝐶 ′ =EK(...) ). After receiving cipher text and parameters, User generates a random number y  𝑍𝑃∗ and decrypts the cipher text C. User calculates the new session key 𝑘 ′ = 𝑔 𝑥𝑦 and produces the session key K=H (𝑘 ′ ) by hash function, and then stores the session key into the mobile phone.. 政治大. Later, User calculates Y = 𝑔 𝑦 mod p and encrypts the cipher text 𝐶 ′ = EK. 立. (𝐼𝐷𝑈 , 𝐼𝐷𝐵 , Timestemp, H(𝐼𝐷𝑈 , 𝐼𝐷𝐵 , Timestemp)) including User name, Issuer name. ‧ 國. 學. and timestamp by new session key K. User → Issuer: (Y, 𝐶 ′ ). ‧. io. 6. Issuer: (AID information, Ticket U,TSP ). al. v i n information C h generated in Ustep4 by engchi. n Issuer will encrypt the. sit. y. Nat. User sends Y and 𝐶 ′ to Issuer. er. 5.. Users’ session key. EK (AID, AIDExtime , AIDLimit , Ticket U,TSP ) and deliver it to User. After generated new session key, Issuer will verify User information and produce User’s virtual account (AID) and information, such as AID expiration date (AID_Extime), AID limit of consumption amount (AID_Limit), the session key between User and TSP 𝐾𝑈,𝑇𝑆𝑃 , User’s ticket 𝑇𝑖𝑐𝑘𝑒𝑡𝑈,𝑇𝑆𝑃 which can help TSP to verify User’s information. The content of ticket is. 50.

(52) Ticket U,TSP = EKI,TSP ((𝐼𝐷𝐼𝑠𝑠𝑢𝑒𝑟 , AID, AIDExtime , AIDLimit , Timestemp2, K U,TSP , Lifetime) ||Sig SKI (IDIssuer , AID, AIDExtime , AIDLimit , Timestemp2, K U,TSP , Lifetime)) The Ticket U,TSP is encrypted by key 𝐾𝐼,𝑇𝑆𝑃 . 𝐾𝐼,𝑇𝑆𝑃 is only known by Issuer and TSP. 7.. Issuer → User: (EK (AID, AIDExtime , AIDLimit , Ticket U,TSP )). Issuer will encrypt the information to EK (AID, AIDExtime , AIDLimit , Ticket U,TSP ) by. 政治大. session key K and deliver it to User.. 立. User: ( DK (EK (AID, AIDExtime , AIDLimit , Ticket U,TSP ) ) ). 學. ‧ 國. 8.. After the receipt of the information delivered by Issuer, User will decrypt it to obtain. ‧. relevant information of AID information and information of TSP communication.. y. Nat. n. er. io. al. sit. Applying AID as shown in Figure 12.. Ch. engchi. 51. i n U. v.

(53) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. Figure 12. Flow of applying for AID. 4.2.2. Applying for TID and Virtual Credit Cards Stage. Before this stage, User must provide the access permission of the SE to TSP, and the SE needs to produce the public-private key pairs of the SE: 𝑃𝐾𝑆𝐸 , 𝑆𝐾𝑆𝐸 . The goal of 52.

(54) this step is to apply for the TID account and the virtual credit card to TSP by User’s AID and others information. User will send the information to TSP and request to apply for the virtual transaction account (TID) and the virtual credit card. First, User is needed to establish new session key with TSP. 1.. User :( 𝑋𝑈 , EKU,TSP (TID − request, IDIssuer , AID, g XU ) ). User selects a random number 𝑋𝑈 , and encrypt 𝑋𝑈 , the applying request TID TID –. 政治大 , AID, g ).. request, Issuer’s information 𝐼𝐷𝐼𝑠𝑠𝑢𝑒𝑟 , AID and 𝑇𝑖𝑐𝑘𝑒𝑡𝑈,𝑇𝑆𝑃 by key 𝐾𝑈,𝑇𝑆𝑃 to EKU,TSP (TID − request, IDIssuer. 立. User → TSP: (EKU,TSP (TID − request, IDIssuer , AID, g XU ), 𝑇𝑖𝑐𝑘𝑒𝑡𝑈,𝑇𝑆𝑃 ). ‧ 國. 學. 2.. XU. for verification.. sit. y. Nat. io. TSP: (DKI,TSP (EKI,TSP (Ticket U,TSP ) ),. n. al. DKU,TSP (EKU,TSP (TID − request, Issuer , AID, g XU ))). Ch. engchi. er. 3.. ‧. User sends EKU,TSP (TID − request, IDIssuer , AID, g XU ) and 𝑇𝑖𝑐𝑘𝑒𝑡𝑈,𝑇𝑆𝑃 to the TSP. i n U. v. After receiving 𝑇𝑖𝑐𝑘𝑒𝑡𝑈,𝑇𝑆𝑃 , TSP will decrypt the 𝑇𝑖𝑐𝑘𝑒𝑡𝑈,𝑇𝑆𝑃 by using key 𝐾𝐼,𝑇𝑆𝑃 and obtains the session key K U,TSP with User. Then, TSP checks whether this AID is the same with the one in the certificate. After that, TSP generates a random number 𝑌𝑇𝑆𝑃 and calculates a new session key 𝐾𝑈 ′ ,𝑇𝑆𝑃′ = H(𝑔 𝑋𝑈𝑌TSP mod p) then TSP connects to User’s SE for setting up. 4.. Connect and access to SE by TSP, as shown in Figure 13.. 53.

(55) 政治大. 學 Figure 13. Flow of TSP access user’s SE. Nat. sit. y. ‧. ‧ 國. 立. io. n. al. er. 4.1 TSP → SE: (PK TSP , Cert TSP ). i n U. v. TSP delivers the TSP public key PK TSP and the certificate Cert TSP to SE.. Ch. engchi. 4.2 After receipt of the certificate and confirmation of the TSP identity, the SE will produce a random number N, then encrypt N and 𝑃𝐾𝑆𝐸 by 𝑃𝐾𝑇𝑆𝑃 to EPKTSP (𝑃𝐾𝑆𝐸 , 𝑁) and generate session key by hashing N, 𝐾𝑆𝐸,𝑇𝑆𝑃 = H(N). 4.3 SE → TSP: (𝐸𝑃𝐾𝑇𝑆𝑃 (𝑃𝐾𝑆𝐸 , 𝑁)) SE delivers the encrypted message E𝑃𝐾𝑇𝑆𝑃 (𝑃𝐾𝑆𝐸 , 𝑁) to TSP. 4.4 TSP: (DSKTSP (𝐸𝑃𝐾𝑇𝑆𝑃 (𝑃𝐾𝑆𝐸 , 𝑁), 𝐾𝑆𝐸,𝑇𝑆𝑃 = H(N), E𝐾𝑆𝐸,𝑇𝑆𝑃 (𝑁 + 1))) After TSP’s receipt of the information of SE, it decrypts ciphertext and obtains a 54.

(56) random number N, then generate session key 𝐾𝑆𝐸,𝑇𝑆𝑃 by N. After that, TSP encrypts N+1 by 𝐾𝑆𝐸,𝑇𝑆𝑃 then sends to SE.. 4.5 TSP → SE:( E𝐾𝑆𝐸,𝑇𝑆𝑃 (𝑁 + 1)) The TSP delivers E𝐾𝑆𝐸,𝑇𝑆𝑃 (𝑁 + 1) to the SE. 4.6 TSP → SE: (N+1) SE verifies the correctness of N+1, so as to confirm the whether the delivery process has been modified.. 政治大. 立. ‧ 國. 學. 4.7 SE → TSP: (E𝐾𝑆𝐸,𝑇𝑆𝑃 (𝑟𝑒𝑠𝑢𝑙𝑡)). SE encrypts the result (success or fail)by 𝐾𝑆𝐸,𝑇𝑆𝑃 to E𝐾𝑆𝐸,𝑇𝑆𝑃 (𝑟𝑒𝑠𝑢𝑙𝑡) and sends to. y. Nat. io. al. sit. TSP (Block 1, 𝐶𝑒𝑟𝑡𝑢′ 𝑐𝑎𝑟𝑑 ). er. 5.. ‧. TSP.. v. n. After receiving SE’s public key, TSP produces the TID and issues the virtual credit. Ch. engchi. i n U. card, certificate and block 1. This block contains Users’ TID account, TID limit and expiration date, which are signed by the TSP, as shown in Figure 14.. Figure 14. Block 1 55.

(57) The certificate of virtual credit cards including: 𝐶𝑒𝑟𝑡𝑢′ 𝑐𝑎𝑟𝑑 = 𝑆𝑖𝑔𝑆𝐾 𝑇𝑆𝑃 {TSP, 𝐼, 𝑇𝐼𝐷, 𝑃𝐾𝑆𝐸 , 𝑁, 𝐹, 𝐸}, I is Users’ Issuer identify and public key of Users’ SE, N is quota limit of the virtual credit card, F is the number allowed to the off-line transaction, and E is the expiration date of the card. TSP records TID and User’s AID into the TSP database. 6.. TSP → User: (EK. U′,TSP′. (Cert u′ card , TID, block 1), 𝑔𝑌𝑇𝑆𝑃 ). TSP encrypts the certificate of virtual credit card and block1 by session key K U′ ,TSP′ to EK. 政治大. (Cert u′ card , TID, block 1), then delivers it with 𝑔𝑌𝑇𝑆𝑃 to User.. 立. ‧ 國. User: (𝐾 𝑇𝑆𝑃′ ,𝑈 ′ = 𝑔𝑌𝑇𝑆𝑃 𝑔 𝑋𝑈 , DK. U′ ,TSP′. (𝐸K. U′ ,TSP′. (𝐶𝑒𝑟𝑡𝑢′ 𝑐𝑎𝑟𝑑 , 𝑇𝐼𝐷, 𝑏𝑙𝑜𝑐𝑘 1)) ). 學. 7.. U′ ,TSP′. ‧. After receiving 𝑔𝑌𝑇𝑆𝑃 User can calculate session key 𝐾 𝑇𝑆𝑃′ ,𝑈′ , User decrypts the cipher text to obtain the certificate of the virtual credit card and the and block, then. y. Nat. al. n. User → SE: (block 1). er. io. 8.. sit. stores it into the mobile phone.. Ch. engchi. User delivers the block 1 to SE for verification. 9.. i n U. v. SE: (𝑟1, ℎ1 = (𝑟1 , block1)). SE choose a random number 𝑟1 after receipt of the block 1 and calculates a hash value by hash function of the block 1, ℎ1 = H(𝑟1 , block1), then stores hash result ℎ1 in the SE. 10. SE → User: (Record Success) SE responds Record Success to User 56.

(58) After the completion of this step, User will obtain the consumable TID virtual credit card. The AID consumable value will be larger than TID credit card, so in the process of consumption, there will be no circumstance like that User can overdraw consumption because the total amount of the TID credit card is never greater than AID amount. Apply for TID and virtual credit cards show as figure 15.. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 57. i n U. v.