transaction process, the detail of the transaction was introduced in section 4, we don’t discuss here. EMV Off-line payment flow chart show as Figure 22
In this stage, User will store certificate and last block n in Dataemv, if User was dealing before then User will store last merchant’s certificate in Dataemv.
1. (M->User) Merchant sends “select the application commend” to user
2. (User->M) User send FCI commend to the merchant which including type and last merchant’s public key or TSP’s public key, FCI = {type,last merchant’s public key or TSP’s public key}
3. (M->User, Get Processing Options) The merchant send “Get Processing Options” commend to user which including CertMacq, PKacq
4. User checks two certificates, if failure then aborts the session.
GET PKM form CertMacq ACT = ACT +1
EPKM(ACT||PK𝑆𝐸||Token)
SetEPKM (ACT||PK𝑆𝐸||Token)in expected file location
5. (User->M, Get Processing Options) User sends AIP and AFL to the merchant.
6. (User->M, Get Data) The merchant uses “Get Data” instruction to access User’s data.
‧
“Read record” instruction and accesses the data which User stored in AFL in the step 4. Then the merchant can check ATC in block n is equal to ACT-1 and PK𝑆𝐸,Token is equal to PK𝑆𝐸,Token in Certu′card
If the verify is fail, the merchant will abort the transaction. Otherwise, the merchant generates “Generate AC” instruction
Generate AC includes Req and Datacdol1 data. Req is representing the transaction type which chosen by merchant. There are two types in Req, one is TC which means to deal in offline mode, and the other is ARQC which is means online mode. Datacdol1 is representing the transaction detail. Then the merchant sends Generate AC to User.
9. (M->User, Generate AC) Req, Datacdol1
Step 1 to 9 is same as consumption stage’s step 1 to 3, User gives merchant the identify of User and the merchant gives User the identity of the merchant.
10. User Checks Datacdol1 and Req then sends Req to SE 11. (User -> SE) Req
12. SE generates the signature (SDAD) which is SE signed Req,Timestamp(TS),ACT,counter by SKSE. SDAD = SigSKSE(Req,TS, ACT, counter)
Then SE generates AC1 which is the hash value by hashing SDAD. AC1 = H(SDAD) 13. (SE->User) SDAD,AC1
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
14. (User->M, Generate AC) Req, SDAD, AC1
15. The merchant ensures SE’s transaction mode by checking SDAD,Req,AC1. Then the merchant generates new block which including current transaction detail and signed by SKM.
Step 10 to 15 is making SE and merchant conform the transaction mode.
16. (M->User, Generate AC) Blockn+1
This step is same as consumption stage’s step 3.
17. (User -> SE)User receives last block and checks block’s content if success then user will send block to SE.
This step is same as consumption stage’s step 4 and 5.
18. After SE receives block n, SE will verify and sign block n+1 which we called block n+1*. The block n+1* is including the SE’s signature, 𝑟𝑛 and ℎ𝑛. And SE generates AC2, which is hash value by hashing block n+1*. AC2=H(Blockn+1∗)
This step is same as consumption stage’s step 6.
19. (SE->User) Blockn+1∗, AC2.
This step is same as consumption stage’s step 7.
20. User updates the 𝑃𝐾𝑀 and Blockn+1∗ to Dataemv. 21. (User->Merchant) Blockn+1∗, AC2
This step is same as consumption stage’s step 8.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 23. Flow chart of EMV compatible instructions (off-line part)
‧
21. The merchant receives block n+1* form User and verify block n+1*
This step is same as consumption stage’s step 9.
End of off-line transaction
The On-line verify part show as Figure 23.
22. (M->I) Block n+1*,Req,Datacdol1,ACT,SDAD,AC1,AC2
The merchant sends block n+1*, Req, Datacdol1, ACT, SDAD, AC1, AC2 to Issuer.
23. Issuer receives the data form the Merchant then verifies. Because SDAD including the transaction time, so the Issuer can verify SDAD by checking time is almost equal to current time. If both times are gapping too much then Issuer will set ARC to fail.
Otherwise, Issuer set ARC to Success. Next, Issuer verifies other data; if data is incorrect then set ARC to Fail. Finally, Issuer generates the signature which including ARC and H(ARC), Sig𝑆𝐾𝐼𝑠𝑠𝑢𝑒𝑟(ARC||H(ARC)).
24. (I->M) SigSK
Issuer(ARC||H(ARC))
25. (M->User, External Authentication) SigSKIssuer(ARC||H(ARC))
When Merchant receives ARC form Issuer then verifies, if verify is success then merchant will generate External Authentication instruction which including Issuer’s signature and send to user.
26. User receives Issuer’s signature and send to SE for verifying.
27. (User->SE) SigSKIssuer(ARC||H(ARC))
28. If ARC is success then SE will not use current private key anymore then update last merchant’s public key and block n+1 to Dataemv and return ACK to User.
29. (SE->User) ACK 30. (User->M) ACK
The merchant receives ACK and verifies ACK.
End of on-line verify.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
The re-register of TID and request payment in consumption stage are not necessary to compatible of EMV. So we don’t show those step in here.
Figure 24. Flow chart of EMV compatible instructions (on-line part)
‧
In this section, we will discuss our protocol running time. EMV standard provisions of the contactless transaction need to be under 0.5 second.
In this test, we used Intel 5 3.2G/Hz dual core CPU, 4G ram, windows 7 home OS, the program language is python and running surrounding is the mobile phone simulator; Bluestack. The universal cell phones are 2.3G/Hz dual core CPU and 2G ram, this test surrounding will not be much better than the universal cell phones. So, our test running time is very close the real cell phone running time.
In our test, we assume the NFC transmission speed can reach 424K bits per second [19] that’s 53000 bytes per second. So, the transmission time is n/53000 per second, n is transmission data size. In addition, we assume all parties have 2048 bits key to encrypt and signature, and use sha-256 to be hash function. In the first transaction step, User will trans user’s certificate, TBC both are included in DataEMV.
In the second step is the merchant verifies the TBC and signs, then generates new block, after that, the merchant sends those message in the second Generate AC instruction.
In the last step, User sends data to SE which received from the merchant. User sends data to SE we assume there don’t cost any time. Then SE will verify TBC and sign TBC. After that, SE will send data to User then User will send to the merchant. This transmission also in the second Generate AC2 instruction.
So, the total running time is combining those three transmission steps time. That’s Although our test didn’t include all EMV transaction steps, but our protocol cost time is far less than 0.5s. So, even including all EMV transaction steps, our protocol cost time will not exceed 0.5s.
Table 5 EMV step cost time
Frist Step Second Step Last Step
Cost time(ms) 11.6 27 7
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
8. Conclusion
Although the contactless payment is more and more mature, but there have many payment still relay on contacting the back to identify users and credit card. However, in the off-line surroundings, the authentication can only be done by users and merchants without the assistant of on-line third party. In this research, we propose a new protocol which can protect users and merchants safety in the situation which malicious users can intercept and tamper with the information. And malicious merchants or other third parties cannot get all user’s information which including AID, TID, virtual credit card etc. So, if User’s information is being intercepted or tampered during a transaction or apply the virtual credit card, the malicious attacker still cannot use User’s card to consume.
Our protocol not only can protect the double spending attack in off-line transaction, but also can ensure if the malicious attacker lunches the double spending, the merchant will find out. However, our protocol also can keep the anonymity of user and transaction efficiency. In this study use the EMV instruction to make our protocol compatible with current EMV standard and hope we can apply it in real life.
Finally, as a future work we hope to keep the anonymity and efficiency on one hand, and to reduce the commutation cost on other hand.
‧
mobile wallet." In Proceedings of Intelligence in Next Generation Networks;International Conference on IEEE, 13th, ICIN, 2009, pp. 1-6.
[2] H. C. Cheng, J. W. Chen, T. Y. Chi & P. H. Chen. "A generic model for NFC-based mobile commerce." In Proceedings of Advanced Communication
Technology; International Conference on IEEE, 11th, ICACT, 2009, pp. 2009-2014.
[3] M. Pasquet, J. Reynaud & C. Rosenberger. "Secure payment with NFC mobile phone in the smart touch project." In Proceedings of Collaborative Technologies and
Systems; International Symposium on IEEE, CTS, 2008, pp. 121-126.
[4] J. C.Paillès, C. Gaber, V.Alimi & M. Pasquet. "Payment and privacy: a key for the development of NFC mobile." In Proceedings of Collaborative Technologies and
Systems; International Symposium on IEEE, CTS, 2010, pp.378-385.
[5] L. Mainetti, L. Patrono & R. Vergallo. "IDA-Pay: an innovative micro-payment system based on NFC technology for Android mobile devices." In Proceedings of
Software, Telecommunications and Computer Networks; International Conference on IEEE, 20th, SoftCOM, 2012, pp.1-6.
[6] ur. Rehman, Shafiq & J. Coughlan. "An efficient mobile payment system based on NFC technology." In Proceedings of World Academy of Science, Engineering and
Technology; International Conference on World Academy of Science, Engineering and Technology, WASET, 2013, pp. 1701-1705.
[7] P. Urien & S. Piramuthu. "Securing NFC mobile services with cloud of secure elements" In Proceedings of Mobile Computing, Applications and Services;
International Conference on Mobile Computing, Applications, and Services, MobiCASE, 2013, pp.322-331.
[8] P. Urien. "EMV-TLS, a secure payment protocol for NFC enabled mobiles." In
Proceedings of Collaboration Technologies and Systems; International Conference on IEEE, CTS, 2014, pp.203-210.
[9] Apple Pay, https://zh.wikipedia.org/wiki/Apple_Pay, 2016
‧
[11] EMV Payment Tokenization Specification – Technical Frameworkv1.0, https://www.emvco.com/download_agreement.aspx?id=945, 2014[12] M. Blaze, J. Ioannidis & A. D. Keromytis. "Offline micropayments without trusted hardware." In Proceedings of Financial Cryptography; International
Conference on Financial Cryptography, 5th, 2001, pp. 21-40.
[13] R. L. Rivest & A. Shamir. "Pay Word and MicroMint: two simple micropayment schemes." In Proceedings of Lecture Notes in Computer Science; International
Workshop on Security Protocols, 1996, pp. 69-87
[14] X. Dai, O. Ayoade & J. Grundy. "Off-line micro-payment protocol for multiple vendors in mobile commerce." In Proceedings of Parallel and Distributed Computing,
Applications and Technologies; International Conference on IEEE, 16th, PDCAT,
2006. pp. 197-202.[15] A. Esmaeeli & M. Shajari. "Mvpayword: Secure and efficient payword-based micropayment scheme." In Proceedings of Applications of Digital Information and
Web Technologies; International Conference on IEEE, 2th, ICADIWT, 2009, pp.
609-614.
[16] L. M. Fan & J. X. Liao. "Discrete micropayment protocol based on master-slave payword chain." In The Journal of China Universities of Posts and
Telecommunications, 2007, pp. 58-84.
[17] C. I. Fan, Y. K. Liang & C. N. Wu. "An anonymous fair offline micropayment scheme." In Proceedings of Information Society; International Conference on IEEE, 2011, p. 377-381.
[18] S. Mendoza. "SamsungPay: Tokenized Numbers, Flaws and Issues."
https://www.blackhat.com/docs/us-16/materials/us-16-Mendoza-Samsung-Pay-Tokeni zed-Numbers-Flaws-And-Issues-wp.pdf, 2016, pp. 1-11
[19] Information technology - Telecommunications and information exchange between systems - Near Field Communication Interface and Protocol -2 (NFCIP-2), ISO/IEC 21481: 2012, 2012
‧
[23] Luhn check digit, https://en.wikipedia.org/wiki/Luhn_algorithm, 2016
[24] M. H. Yang. "Security enhanced EMV-based mobile payment protocol." In The
Scientific World Journal, 2014, pp. 1-19.
[25] 羅嘉寧 & 楊明豪 "基植於 NFC 系統之匿名行動付款協定" In Journal of
Information, Technology and Society, 2014, pp. 19-32.
[26] 陳尚文, "基植於NFC系統之匿名行動付款協定之研究與改良" 政治大學資 訊科學研究所學位論文, 2016
[27] R. Martínez-Peláez, F. Rico-Novella & C.Satizábal. "Mobile payment protocol for micropayments: withdrawal and payment anonymous." In Proceedings of New
Technologies, Mobility and Security; International Conference on IEEE, 2008, pp.
1-5.
[28] Y. Chen, J. S. Chou, H. M. Sun & M. H. Cho. "A novel electronic cash system with trustee-based anonymity revocation from pairing." In The Journal of Electronic
Commerce Research and Applications, 2011, pp. 673-682.
[29] S. K. Noh, S. R. Lee & D. Y. Choi. "Proposed m-payment system using near-field communication and based on WSN-enabled location-based services for m-commerce." In The Journal of Distributed Sensor Networks, 2014, pp. 1-9.
[30] F. Kerschbaum, H. W. Lim & I.Gudymenko. "Privacy-preserving billing for e-ticketing systems in public transportation." In Proceedings of the Workshop on
privacy in the electronic society; International ACM Conference on Computer and Communications Security, 20th, ACMCSS, 2013, pp. 143-154
[31] G. Van Damme, K. M. Wouters, H. Karahan & B. Preneel. "Offline NFC
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
payments with electronic vouchers." In Proceedings of the workshop on Networking,
systems, and applications for mobile handhelds; International ACM Conference on the Special Interest Group on Data Communication, 1st, ACM SIGCOMM, 2009, pp.
25-30
[32] 洪聖翔, "相容 EMV 具雙向認證且適合離線及線上交易之行動付款協定."
中原大學資訊工程研究所學位論文, 2013.
[33] 何宇承, "相容 EMV 具雙向認證之離線行動付款協定." 中原大學通訊工程 碩士學位學程學位論文, 2015.
[34] EMVCo, EMV - Integrated Circuit Card Specifications for Payment Systems, Version 4.3 ed., EMVCo, LLC, 2011
[35] Web API For Accessing Secure Element v1.0,
https://globalplatform.github.io/WebApis-for-SE/doc/, 2016 [36] 離線支付,
http://wiki.mbalib.com/zh-tw/%E7%A6%BB%E7%BA%BF%E6%94%AF%E4%BB
%98, 2014