EMV-Compatible Offline Mobile Payment Protocol with Mutual Authentication
Abstract
:1. Introduction
2. EMV-Based Offline Payment with Mutual Authentication
- Issuer: responsible for managing the application of credit cards and the issuance of offline transaction certificates. The issuer also communicates with the acquirer that deploys POS terminals through a secured financial network;
- NFC mobile phone: used to store a virtual credit card in a secure element, and inductively transfers transaction data with the merchant’s POS. When a user wants to make an offline transaction, he must first apply for an offline transaction certificate from the issuer.
- Merchant: deploys a POS to read the NFC mobile phone; transaction data received by the merchant are transmitted to the acquirer through a secure channel. Merchants can conduct online or offline transactions with the user.
- Acquirer: receives the transaction data from the merchant and confirms the correctness of the transaction through the financial network. In offline transactions, the merchant cannot connect the acquirer to check if a credit card has been revoked.
2.1. Generation of Offline Transaction Certificates
2.1.1. (a) Generation of Secret Factors
2.1.2. (b) Credit Quota Calculation Method
2.1.3. (c) Issuance of Offline Certificates and Credit Quota Calculation Method
2.1.4. (d) Use of the Credit Quota
2.1.5. (e) Credit Quota Verification
- and are used to calculate the correctness;
- the issuer’s public key is employed to decrypt to obtain , and it is checked whether can be calculated back to to verify that the obtained hash value is correct;
- the merchant checks that the forced addition to by the user is less than the applied amount n;
- the merchant checks that is the merchant’s own ID.
- the issuer verifies the merchant identity ;
- the issuer checks whether is in the merchant list M;
- the issuer obtains the serial number of the secret factor of the hash chains and and checks the corresponding hash value secret factors and ;
- the issuer checks that the derived is the same offline certificate and credit quota that was supplied by the user.
2.2. Merchant’s Identity
2.3. Compatibility with the EMV Protocol
2.4. Phase 3: Offline Certificate Application and Split Credit Quota Authorization
2.4.1. Phase 3 Process Diagram
- (2a-1) the phone applies to the issuer for a certificate and the split credit quota authorization required for transactions.
- (2a-2) the issuer generates the offline certificate, transaction authorization, and credit quota required to split the certificate. The certificate is stored in the secure element of the phone upon receipt.
- (2b) the phone sends a message containing the offline certificate to the merchant.
2.4.2. Phase 3 Protocol
- Message 1When the user’s phone receives a GENERATE AC command [1] containing an offline certificate request cryptogram (OCRC) [45], the phone first decrypts to retrieve by using the communication key . The data transferred by the merchant, , serial number of the transaction, [1], and a random number obtained in mutual authentication, [45], are used to generate a message authentication code with the hash function by using the shared key, , with the issuer:
- Message 2The phone encrypts the , , and that were originally to be transmitted according to the protocol using and sends them back to the merchant to begin the offline certificate application phase.
- Message 3After receiving the message from the phone, the merchant decrypts , , and by using . Subsequently, in addition to sending the decrypted data and the generated in mutual authentication to the issuer, the merchant informs the issuer of the longest offline duration to be used, [45], so that the issuer can set the expiration time of the offline certificate according to the offline transaction environment.
- Message 4Once the issuer receives the request message for offline certificate application, it uses the shared key , , , and in the message to calculate and determine whether the code in the message sent by the merchant is correct. If the message is incorrect, the authorization response code () is set to fail. Otherwise, the is set to success, and the issuer starts to generate the parameters and transaction verification message required for issuance of the offline transaction certificate and credit control:
- Randomly generated numbers and are used to create the corresponding serial numbers and , and and are stored in .
- The of the issuer is employed to encrypt the random and serial numbers to generate secret factors representing the credit quota and offline transaction merchant :
- The hash values of and are calculated and placed into the reverse hash chain set W and forward hash chain set S:
- All authorized merchant identities are placed in the authorized merchant set M.
- A is generated that enables the issuer to authenticate the transaction message.
- A b is generated that represents the current user’s amount spent. Because the amount has not been used at the application phase, .
- The issuer’s is used to perform asymmetric encryption on the last item of the credit quota hash chain for issuer endorsement. During the transaction, the merchant confirms the correctness of and calculates and verifies that the amount received is correct.
- Asymmetric encryption is performed using the credit card’s public key , inserting the (a) shared key of the user and issuer; (b) secret factor of the limit hash chain; (c) serial number of ; (d) , which represents the secret factor of the merchant’s hash chain; (e) serial number of ; (f) amount to be spent b; (g) after has been endorsed by the issuer; and (h) apart from necessary amount data, a random number , which prevents the amount spent message from being resent:
- According to EMV standards, the sent by the merchant, and the user’s credit assessment, the issuer generates , an X.509 certificate [50]. This certificate includes the issuer (), user’s credit card account (), offline certificate expiration time (), consumption upper limit (n), and all authorized merchant identities (M).
Finally, the issuer uses to generate a message authentication code ARC) by using the mutually exclusive results between and . Subsequently, this message authentication code, , the encrypted by the phone’s , and are sent to the merchant. - Message 5If the merchant receives a reply from the issuer that the fails, the offline certificate application process is terminated. However, a successful indicates that the issuer agrees to send an offline certificate. The merchant uses the EXTERNAL AUTHENTICATION command marked in the unused parameter field [1] to transfer the offline certificate to the user’s mobile phone [45]. In addition, is placed in this unused parameter field.Decryption and verification are performed after the phone has received ARCARC and :
- Decryption is performed using , and the received, calculated at the beginning of the protocol, and are used to calculate the message authentication code ARC) to confirm that it is similar to the code received.
- is employed to decrypt the offline certificate and inspect its source. The phone sets the inspection result to fail for a failed message authentication code and offline certificate verification.
- If the message received is verified to match the correct , the certificate is placed in the list, making .
- The of the credit card is used to decrypt the asymmetric encryption of Lim to obtain , , , , , b, , and and store them in the secure element for protection to prevent users from arbitrarily modifying the essential parameters and data of their offline transactions. Once the phone receives it, the Lim is sent directly to the secure element for decryption. The phone plays a mediating role between the merchant and secure element.
- The issuer’s public key is employed to decrypt the asymmetric encrypted to obtain the generated by the issuer, and whether is equal to the obtained by decrypting after n hash function calculations is determined. If , the fails; otherwise, the is success, with . The forced added counter in the secure element adds up the amount of each purchase to the counter until the upper limit n is reached; reapplication is then required to continue making offline transactions.
- Message 6Finally, the phone returns the to the merchant. If the fails, the merchant must reapply for a certificate. Otherwise, the user’s phone saves the offline certificate, and the phone does not need to reapply for an offline certificate in the next transaction if the message received by the merchant contains , which indicates that offline transaction can commence immediately.
2.5. Phase 4: Offline and Online Transactions
- Message 7Once the phone receives the GENERATE AC command with parameter , is used to decrypt the transaction data to obtain , and the user confirms that the transaction amount in is correct. The phone then executes the following three steps in accordance with the EMV payment requirements:
- -
- A message authentication code is generated from the , , and using the issuer’s . .
- -
- ,, , the of , , and the for generating are calculated.
- -
- Encryption is performed using the EMV credit card’s to generate the signed dynamic application data (SDAD) from , , , and the hash function generated in the previous step.The data stored in the secure element during the application phase are retrieved for verification and calculation, and transaction verification and payment messages are generated:
- The sent by the merchant must be present in the authorized merchant list M of ; if it is not, the transaction is canceled immediately.
- The amount spent b is employed to calculate the used hash value . Moreover, the transaction amount c is used to calculate the paid hash value . The amount spent is a reverse hash chain, and the hash is a one-way irreversible function; thus, the actual method for calculating the hash value is as follows:
- The merchant code is calculated. In the first purchase, and . Each transaction generates a hash value representing the merchant, and the shared key is used for encryption so that the merchant is unaware of ; nonetheless, it does represent the merchant participating in the transaction.
- The amount c is spent in the transaction; thus, the amount spent becomes .
- The current purchase amount c is added to , such that .
- A verification message is generated for the issuer, and the offline transaction authentication key , which was obtained by the secure element during the application is used to represent the merchant’s identity hash value , serial number of , serial number of , and placed in during the application phase; these are symmetrically encrypted to become .
- A verification message is generated for the merchant, and the of the credit card is employed to asymmetrically encrypt the issuer verification message , amount after issuer endorsement , hash value of the amount spent , hash value of the payment amount , current amount spent c, offline transaction amount counter, and merchant’s identity into .
- Message 8The mobile phone encrypts , , , , and , which are returned to the merchant through the use of . The newly added message content is placed in the RFU of GENERATE AC for transfer to achieve an EMV-compatible protocol.The merchant receives the returned message from the mobile phone and performs two decryption and six verification actions:
- -
- is used to decrypt and extract , , , , and .
- -
- is employed to decrypt and obtain , and ’, and the issuer’s public key is used to decrypt to obtain :
- The is decrypted using , and the hash function is verified.
- ’ in is equal to .
- Whether current time meets the limited by the is checked.
- Whether the counter limit has not exceeded the offline transaction amount n set in the offline certificate is checked.
- The correctness of is calculated. Using , where , it is determined whether and are in the same hash chain. Whether is equal to after c hash function calculations is determined, and the calculation method is .
2.6. Phase 5: Payment Request by the Merchant
- Step 5: the merchant sends the self-verified message, issuer-verified message, and payment information to the issuer to request verification of the transaction’s correctness.
- Step 6: if the transaction is verified, the merchant can request payment from the issuer.
- It is verified that and are in the W hash value set generated during the application phase and the merchant representative hash value is in the S hash value set.
- Whether in is present in the list of authorized merchants of the offline certificate is determined.
- The preposition , where , is considered to determine whether and are in the same hash chain and thus confirm their correctness. Whether equals after c hash function operations is determined, and its calculation method is .
- Whether exceeds the limit n is checked.
- It is confirmed that the in is equal to the placed in during the application phase.
3. Security Analysis and Performance Evaluation
3.1. Security Analysis
- Verifiability:
- In phase 4, the merchant can immediately verify the verification message of the offline transaction.
- In phase 5, the issuer obtains transaction verification messages (for the merchant and issuer) from the merchant and verifies all the information obtained to ensure the correctness of the transaction.
- Counterfeiting prevention:
- In phase 3 (2a-2), the issuer provides the user and merchant with the encrypted hash value of the final item of the user’s credit quota chain so that they can verify the amount of the hash value (as shown in Figure 4). Attackers cannot encrypt the cipher text without the issuer’s private key.
- In message 7 of phase 4, the amount spent b information given to the merchant is protecvalue by the user is asymmetrically encrypted using the credit card private key : , and the merchant requests payment from the issuer after confirmation. Incorrect amount information generated by the user is immediately detected by the merchant. Similarly, the merchant cannot falsify the information given by the user to request a higher amount from the issuer.
- Tampering prevention:
- In the application phase, the offline transaction certificate and credit quota limit information are encrypted using the virtual credit card’s public key and the key shared between the user and issuer, enabling the issuer to protect the message content. In addition to the credit quota hash chain’s secret factor , the credit quota message contains cipher text encrypted using the issuer’s private key.
- If the secret factor is not calculated by the original issuer, different hash values obtained during the verification will cause failure of the verification.
- The verification message given to the merchant in message 8 of phase 4 is encrypted using the virtual credit card’s private key , which is stored in the secure element. Even if malicious software is installed on the user’s mobile phone, the content encrypted by the secure element is not easily modified.
- Replay attack prevention:
- In the application phase, the issuer places a random number in the credit quota message and passes it to the user. The user places the random number in the issuer verification message (as shown in Figure 9 and passes it to the merchant during a transaction. The merchant sends this message to the issuer during their payment request. The issuer then checks whether the random number is the same as that given by the issuer to the user during application and whether the corresponding amount is the amount originally given as the hash value.
- Nonrepudiation:
- In phase 4, in addition to having a transaction message, the user has a verification message (to be given to the merchant) that is encrypted using the virtual credit card’s private key to generate the signed dynamic application data (SDAD) from , , , which ensure that the message is sent by the user. The user cannot deny that they have created this message.
- The issuer verification message also contains two corresponding hash values ( and ) for the transaction that the merchant is not informed of, indicating that the credit quota is for the use of a certain merchant. If the merchant subsequently denies the transaction, the issuer can identify the corresponding merchant during verification.
- Duplicate payment prevention:
- The user cannot cheat the merchant because a is stored in the secure element of the mobile phone and is forced to increase upon every transaction. The value of must be smaller than the transaction usage amount requested by the user. If the user repeatedly uses the amount of the hash value, the counter is still forcibly added to; thus, the amount spent must be lower than the applied amount (e.g., a failed transaction may waste the usable amount because the counter has already been forcibly added to when the user sends out a credit quota limit hash value), and the amount does not expand because of a duplicate payment. If the merchant want to duplicate the payment (as shown in Figure 8), it sends and to the issuer. The issuer will decrypt the message and detect double-spending by using the and are in the W hash value set generated during the application phase.
3.2. GNY Logic Proof
3.3. Performance Analysis
4. Conclusions
Author Contributions
Funding
Acknowledgments
Conflicts of Interest
Notations
Symbols | Definitions |
Publisher signs the certificate issued to the target, and the certificate contains a public key corresponding to the target’s private key. | |
Required certificate for offline transactions. | |
Target’s public key. | |
Target’s private key. | |
A symmetric encryption key shared between the credit card and issuer. | |
A symmetric key shared between the credit card and issuer for calculating the message authentication code. | |
A symmetric key shared between the credit card and issuer for encrypting the offline transaction certificate message provided to the issuer. | |
A communication key for the mobile phone and merchant. | |
A key owned by the issuer for encryption of specific serial numbers and random numbers to generate secret values for the hash function chain. | |
Encryption of message M by using a symmetric or asymmetric key. | |
Decryption of message M by using a symmetric or asymmetric key. | |
In the EMV protocol, a symmetric authentication function and a key are used to calculate the message authentication code function of message M. | |
The hash function and key are employed to calculate the message authentication code function of message M. | |
n | The maximum credit quota during an offline transaction, which also represents the number of hash functions that can be calculated by the hash function chain of the credit quota. |
t | Maximum number of offline transactions. |
m | Number of merchants authorized for offline transactions. |
The first item of the hash function chain, which can perform nth hash function calculations for the limit of offline transactions. | |
The last item in the hash function chain for the credit quota for offline transactions. | |
The first item of the hash function chain, which is used to represent the secret factor of the merchant participating in the offline transaction. | |
The nth item of the hash function chain, which is used to represent the merchant participating in the offline transaction, indicating the merchant corresponding to the nth offline transaction. | |
, | The plaintext i obtained after decryption using the key. |
The table in which the issuer places the and elements. | |
The serial number corresponding to i. | |
The random number used for i. | |
The random number attached to the credit quota issuance. | |
The required content for offline transaction amount management and restrictions. | |
W | A set of hash values for all amounts. |
S | A set of hash values for all corresponding merchants. |
M | A set of all merchants authorized to complete offline transactions. |
The identification name of merchant i. | |
Offline transaction amount counter. | |
The credit quota issued by the issuer. | |
l | The number of calculations of the hash function corresponding to this consumption amount. |
The longest offline transaction duration notified by merchants. | |
Primary account number, which is the user’s credit card account number. | |
Expiry time, which is the effective time taken to complete the offline transaction. |
References
- EMVCo: EMV—Integrated Circuit Card Specifications for Payment System, Version 4.3 ed.; EMVCo, LLC: Foster City, CA, USA, 2011.
- EMVCo: A Guide to EMV Chip Technology, Version 2.0 ed.; EMVCo, LLC: Foster City, CA, USA, 2014.
- De Ruiter, J.; Poll, E. Formal Analysis of the EMV Protocol Suite. In Proceedings of the 2011 international conference on Theory of Security and Applications (TOSCA 2011), Saarbrücken, Germany, 31 March–1 April 2011; Volume 6693, pp. 13–129. [Google Scholar]
- Chen, C.; Tang, S.; Mitchell, C.J. Building General-Purpose Security Services on EMV Payment Cards. In Proceedings of the 8th International Conference on Security and Privacy in Communication Networks, Padua, Italy, 3–5 September 2012. [Google Scholar]
- Murdoch, S.J.; Anderson, R. Security Protocols and Evidence: Where Many Payment Systems Fail. In Proceedings of the 8th International Conference on Financial Cryptography and Data Security, Christ Church, Barbados, 7 March 2014. [Google Scholar]
- Alhothaily, A.; Alrawais, A.; Cheng, X.; Bie, R. Towards More Secure Cardholder Verification in Payment System. In Proceedings of the 9th International Conference on Wireless Algorithms, Systems, and Applications (WASA), Harbin, China, 23–25 June 2014; pp. 356–367. [Google Scholar]
- ECMA INTERNATIONAL: Standard ECMA-340, Near Field Communication Interface and Protocol (NFCIP-1), 3rd ed.; ECMA International: Geneve, Switzerland, 2013.
- ECMA INTERNATIONAL: Standard ECMA-352, Standard ECMA-340, Near Field Communication Interface and Protocol -2 (NFCIP-2), 3rd ed.; ECMA International: Geneve, Switzerland, 2013.
- Information Technology—Telecommunications and Information Exchange between Systems—Near Field Communication Interface and Protocol-1 (NFCIP-1); ISO/IEC 18092:2013; International Organization for Standardization: Geneva, Switzerland, 2013.
- Information Technology—Telecommunications and Information Exchange Between Systems—Near Field Communication Interface and Protocol-2 (NFCIP-2); ISO/IEC 21481:2012; International Organization for Standardization: Geneva, Switzerland, 2012.
- Identification Cards—Contactless Integrated Circuit Cards—Proximity Cards—Part 1–Part 4; ISO/IEC 14443 International Organization for Standardization: Geneva, Switzerland, 2008.
- Giese, D.; Liu, K.; Sun, M.; Syed, T.; Zhang, L. Security Analysis of Near-Field Communication (NFC) Payments. arXiv 2019, arXiv:1904.10623. [Google Scholar]
- Visa payWave—Visa Contactless Payment Specification (VCPS) Version 2.1; Visa Inc.: Foster City, CA, USA, 2009.
- Steffens, E.-J.; Nennker, A.; Ren, Z.; Yin, M.; Schneider, L. The SIM-based Mobile Wallet. In Proceedings of the 13th International Conference on Intelligence in Next, Generation Networks (ICIN), Bordeaux, France, 26–29 October 2009; pp. 1–6. [Google Scholar]
- Cheng, H.C.; Chen, J.W.; Chi, T.Y.; Chen, P.H. A Generic Model for NFC-based Mobile Commerce. In Proceedings of the 11th International Conference on Advanced Communication Technology, Gangwon-Do, Korea, 15–18 Febraury 2009; pp. 2009–2014. [Google Scholar]
- Noh, S.K.; Choi, D.Y.; Kim, H.G.; Kim, D.K.; Seo, J.H.; Kim, J.W.; Cha, B.R. Proposed of Micropayment and Credit Card Model using NFC Technology in Mobile Environment. Int. J. Multimedia Ubiquitous Eng. 2013, 8, 295–305. [Google Scholar]
- Google Corp. Google Wallet. Available online: http://www.google.com/wallet/ (accessed on 22 October 2019).
- Microsoft Corp. Trusted Platform Module (TPM) Virtual Smart Card Management Protocol Specification. Available online: http://msdn.microsoft.com/en-us/library/hh880895(prot.20).aspx (accessed on 22 October 2019).
- Apple Pay, Apple Inc. Available online: https://www.apple.com/apple-pay/ (accessed on 22 October 2019).
- UL’s Independent Assessment, “Apple Pay—What Do We Know?”, White Paper. 2014. Available online: https://www.ul-ts.com/catalog/offerings/knowledge-sharing/whitepapers-and-case-studies/landing/c-29/c-1684 (accessed on 22 October 2019).
- Pasquet, M.; Reynaud, J.; Rosenberger, C. Secure Payment with NFC Mobile Phone in the SmartTouch Project. In Proceedings of the International Symposium on Collaborative Technologies and Systems (CTS), Irvine, CA, USA, 19–23 May 2008; pp. 121–126. [Google Scholar]
- Paillès, J.C.; Gaber, C.; Alimi, V.; Pasquet, M. Payment and Privacy: A Key for the Development of NFC Mobile. In Proceedings of the 2010 International Symposium on Collaborative Technologies and Systems (CTS), Chicago, IL, USA, 17–21 May 2010; pp. 378–385. [Google Scholar]
- Mainetti, L.; Patrono, L.; Vergallo, R. IDA-Pay: An Innovative Micro-Payment System Based on NFC Technology for Android Mobile Devices. In Proceedings of the 20th International Conference on Software, Telecommunications and Computer Networks (SoftCOM), Split, Croatia, 11–13 September 2012; pp. 1–6. [Google Scholar]
- Urien, P.; Piramuthu, S. Securing NFC Mobile Services with Cloud of Secure Elements (CoSE). In Proceedings of the 5th International Conference on Mobile Computing, Applications and Services (MobiCASE), Paris, France, 7–8 November 2013; pp. 322–331. [Google Scholar]
- De Luna, I.R.; Ramos, I.; Montoro-Ríos, F.; Liébana-Cabanillas, F.J. New perspectives on payment systems: Near field communication (NFC) payments through mobile phones. Mob. Commer. Concepts Methodol. Tools Appl. 2018, 1487–1507. [Google Scholar] [CrossRef]
- Yen-Jing, N. Near field communication (NFC) mobile payment in Malaysia: A partial least square-structural equation modelling (PLS-SEM) approach. Int. J. Model. Oper. Manag. 2019, 134–160. [Google Scholar] [CrossRef]
- Park, C.-H.; Park, C.-S. Public Key based Virtual Credit Card Number Payment System for Efficient Authentication in Card Present Transaction. J. Korea Inst. Inf. Secur. Cryptol. 2015, 25, 1175–1186. [Google Scholar] [CrossRef] [Green Version]
- Al-Tamimi, M.; Al-Haj, A. Online Security Protocol for NFC Mobile Payment Applications. In Proceedings of the 2017 8th International Conference on Information Technology (ICIT), Singapore, 27–29 December 2017; pp. 827–832. [Google Scholar]
- Madhoun, N.; Pujolle, G. Security Enhancements in EMV Protocol for NFC Mobile Payment. In Proceedings of the 2016 IEEE Trustcom/BigDataSE/ISPA, Tianjin, China, 23–26 August 2016; pp. 1889–1895. [Google Scholar]
- Haselsteiner, E.; Breitfuß, K. Security in Near Field Communication (NFC). In Proceedings of the RFIDSec’06 on RFID Security, Graz, Austria, 12–14 July 2006. [Google Scholar]
- Madlmayr, G.; Langer, J.; Kantner, C.; Scharinger, J. NFC Devices: Security and Privacy. In Proceedings of the 3rd International Conference on Availability, Reliability and Security (ARES), Technical University of Catalonia, Barcelona, Spain, 4–7 March 2008; pp. 642–647. [Google Scholar]
- Damme, G.V.; Wouters, K.; Preneel, B. Practical Experiences with NFC Security on mobile Phones. In Proceedings of the RFIDSec’09 on RFID Security, Leuven, Belgium, 30 June–2 July 2009. [Google Scholar]
- Nelson, D.; Qiao, M.; Carpenter, A. Security of the Near Field Communication Protocol: An Overview. J. Comput. Sci. Coll. 2013, 29, 94–104. [Google Scholar]
- Levi, M.; Bissell, P.; Richardson, T. The Prevention of Cheque and Credit Card Fraud; Paper No. 26; Crime Prevention Unit: London, UK, 1991. [Google Scholar]
- Bond, M.; Choudary, O.; Murdoch, S.J. Chip and Skim: Cloning EMV Cards with the Pre-Play Attack. Comput. Res. Repos. (CoRR) 2012, arXiv:1209.2531. [Google Scholar]
- Blaze, M.; Ioannidis, J.; Keromytis, A.D. Offline Micropayments without Trusted Harware. In Proceedings of the 5th International Conference on Financial Cryptography, Grand Cayman, British West Indies, 19–22 February 2001; pp. 21–40. [Google Scholar]
- Rivest, R.; Shamir, A. PayWord and MicroMint: Two Simple Micropayment Schemes. In Proceedings of the Security Protocols Workshop on Security Protocols, Cambridge, UK, 10–12 April 1996; pp. 69–81. [Google Scholar]
- Lin, I.C.; Hwang, M.S.; Chang, C.C. The General Pay-Word: A Micro-payment Scheme Based on n-dimension One-way Hash Chain. Des. Codes Cryptogr. 2005, 36, 53–67. [Google Scholar] [CrossRef]
- Fan, L.M.; Liao, J.X. Discrete Micropayment Protocol based on Master-Slave Payword Chain. J. China Univ. Posts Telecommun. 2007, 14, 58–60. [Google Scholar] [CrossRef]
- Fan, C.I.; Liang, Y.K.; Wu, C.N. An anonymous fair offline micropayment scheme. In Proceedings of the 2011 International Conference on Information Society (i-Society), London, UK, 27–29 June 2011; pp. 377–381. [Google Scholar]
- Yen, S.M.; Lin, H.C.; Chen, Y.C.; Hung, J.J.; Wu, J.M. PayStar: A Denomination Flexible Micropayment Scheme. J. Inf. Sci. 2014, 259, 160–169. [Google Scholar] [CrossRef]
- Kim, S.; Lee, W. A PayWord-based Micropayment Protocol Supporting Multiple Payments. In Proceedings of the 12th International Conference on Computer Communications and Networks (ICCCN), Double Tree Lincoln Centre, UK, 20–22 October 2003; pp. 609–612. [Google Scholar]
- Esmaeeli, A.; Shajari, M. MVPayword: Secure and Efficient Payword-based Micropayment Scheme. In Proceedings of the 2nd International Conference on the Web Technologies (ICADIWT), London, UK, 4–6 August 2009; pp. 609–614. [Google Scholar]
- Huszti, A. Multi-Vendor PayWord with Payment Approval. In Proceedings of the International Conference on Security and Management (SAM), Las Vegas, NA, USA, 22–25 July 2013. [Google Scholar]
- Yang, M.H. Security Enhanced EMV-based Mobile Payment Protocol. J. Sci. World J. 2014. [Google Scholar] [CrossRef] [PubMed]
- Liu, M.; Xin, Y.; Yang, Y.; Niu, X. Security Mechanism Research of EMV2000. In Proceedings of the 2007 IEEE/WIC/ACM International Conferences on Web Intelligence and Intelligent Agent Technology–Workshops (WI–IATW), Silicon Valley, CA, USA, 2–5 November 2007; pp. 307–310. [Google Scholar]
- Murdoch, S.J.; Drimer, S.; Anderson, R.; Bond, M. “Chip and PIN is Broken”. In Proceedings of the 2010 IEEE Symposium on Security and Privacy (SP), Berleley/Oakland, CA, USA, 16–19 May 2010; pp. 433–446. [Google Scholar]
- Hancke, G.P. Practical Eavesdropping and Skimming Attacks on High-frequency RFID Tokens. In Proceedings of the 2010 Workshop on RFID Security, Singapore, 22–23 February 2010; pp. 259–288. [Google Scholar]
- Bhole, V.A.; More, R.R.; Khadke, N.C. Security in Near Field Communication (NFC) Strengths and Weaknesses. In Proceedings of the 2nd National Conference on Emerging Trends in Information Technology (EIT); I K International Publishing House Pvt. Ltd.: Delhi, India, 2007; pp. 71–79. [Google Scholar]
- ITU-T Recommendation X.509 Information Technology—Open System Interconnection—The Directory Public-Key and Attribute Certificate Frameworks; ISO/IEC 9594-8:2008; International Telecommunication Union: Geneva, Switzerland, 2008.
- Gong, L.; Needham, R.; Yahalom, R. Reasoning about belief in cryptographic protocols. In Proceedings of the IEEE Computer Society Symposium on Research in Security and Privacy, Oakland, CA, USA, 7–9 May 1990; pp. 234–248. [Google Scholar]
Serial Number | Random Nonce |
---|---|
⋯ | ⋯ |
⋯ | ⋯ |
EOPMA | EPMAR | Al-Tamimi | Modhoun | EMV-CDA | EMV-DDA | EMV-SDA | |
---|---|---|---|---|---|---|---|
Exceeding of a credit quota | O | X | X | X | X | X | X |
Malicous phone | O | O | O | O | O | O | O |
Malicous merchant | O | O | O | O | X | X | X |
Confidentiality | O | O | O | O | X | X | X |
Replay attacks | O | O | O | O | X | X | X |
Data privacy | O | O | O | O | X | X | X |
Integrity | O | O | O | O | O | O | O |
Non-repudiation | O | O | O | O | O | X | X |
MITM attacks | O | O | X | O | O | X | X |
Clone attacks | O | O | O | O | X | X | X |
Fully EMV-Compatiable | O | O | X | O | O | O | O |
I | Issuer |
M | Merchant |
P | User’s NFC phone |
, | Uses the symmetric key K to encrypt/decrypt the message X. |
, | Uses the asymmetric key K to encrypt/decrypt the message X. |
Message X is protected by the one way hash function . | |
P is told message X. | |
P possesses message X. | |
X is generated by others; means P is told for X which he did not convey previously. | |
P believes X is fresh. X has not been used at any time in the prior protocol, or sent by an attacker. | |
For example, a random number or a counter. | |
P believes X is recognizable. | |
P believes S is shared by P and Q. | |
P believes Q owns the private key correspondent to the public key . | |
P believes Q sent X. |
Phone | |
The phone keeps a virtual credit card’s public key, private key, | |
and the shared encryption key. | |
The phone generates a session key with a merchant during a transaction. | |
The phone holds the issuer’s public key. | |
The phone knows the merchant’s ID. | |
Merchant | |
The merchant owns his identity, | |
the shared session key with the phone, | |
credit card’s public key, | |
and the issuer’s public key. | |
Issuer | |
The issuer has its own private key and public key, | |
the shared key with the phone, | |
the transaction key. | |
The issuer knows the merchant’s identity, | |
and uses a random number for verification. |
Phase 3, offline certificate application and split credit quota authorization | |
The phone believes and is generated by the issuer, | |
gets the shared key . | |
Finally both of them believes all the messages are fresh | |
and are recognizable. | |
Phase 4, offline and online transactions | |
The merchant believes the phone has the offline certificate , | |
and he believes is generated by the phone. | |
Finally the two parties believe the is fresh | |
and is recognizable. | |
Phase 5, payment request by merchant | |
Both the issuer and the merchant believe is recognizable, | |
and the issuer believes is recognizable. | |
Phase 3 | ||
Message | The merchant and the issuer has built an secure channel | |
1.1 | /* IA */ | all the messages between them can be trusted. |
/* IA */ | ||
/* IA */ | ||
Message | The phone believes TK is fresh. | |
1.2 | /*T1*/ | believes is generated by the phone. |
/* T3 */ | Finally both of them believes the is fresh | |
/* P1 */ | and is recognizable. | |
/* F3 */ | ||
/* R4 */ | ||
/* F3 */ | ||
/* R4 */ | ||
/* T3 */ | ||
/* P1 */ | ||
/* J1 */ | ||
Phase 4 | ||
Message | The phone believes is fresh, | |
2.1 | /* T1 */ | and is recognizable. |
/* T3 */ | Therefore, is not forged or replayed. | |
/* P1 */ | ||
/* R2 */ | ||
Message | The merchant believes is fresh, and is not forged. | |
2.2 | /* T1 */ | The merchant gets the public key of the credit card. |
/* T3 */ | Therefore, the merchant can vertify the message by . | |
/* P1 */ | ||
/* F4 */ | ||
/* T6 */ | ||
/* P1 */ | ||
/* R3*/ | ||
/* T6 */ | ||
/* T6 */ | ||
/* P1 */ | ||
Message | The issuer and the merchant has established a secure channel, | |
3 | /* IA, T1*/ | all the messages exchanged between them can be trusted. |
The issuer gets phone’s public key , and the shared | ||
key . | ||
/* IA, F4 */ | Therefore, the issuer can verify the message and . | |
. /* IA, R3 */ | ||
/* T6 */ | ||
/* P1*/ | ||
/* F2 */ | ||
/* R2 */ | ||
/* R3*/ | ||
/* T3 */ | ||
/* T3 */ | ||
/* T3 */ | ||
Operations | Time |
---|---|
AES-128 () | 0.15 |
HMAC-128 () | 0.16 |
HMAC-256 ( | 0.25 |
Random number generation | 0.01 |
RSA encrypt () | 0.59 |
RSA decrypt () | 5.67 |
Operations | Phone | Merchant | Issuer |
---|---|---|---|
Phase 1 | 0 | 0 | 0 |
Phase 2 | 0 | 0 | 0 |
Phase 3 | |||
Phase 4 | 0 | ||
Phase 5 | 0 | 0 |
© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Share and Cite
Luo, J.-N.; Yang, M.-H. EMV-Compatible Offline Mobile Payment Protocol with Mutual Authentication. Sensors 2019, 19, 4611. https://doi.org/10.3390/s19214611
Luo J-N, Yang M-H. EMV-Compatible Offline Mobile Payment Protocol with Mutual Authentication. Sensors. 2019; 19(21):4611. https://doi.org/10.3390/s19214611
Chicago/Turabian StyleLuo, Jia-Ning, and Ming-Hour Yang. 2019. "EMV-Compatible Offline Mobile Payment Protocol with Mutual Authentication" Sensors 19, no. 21: 4611. https://doi.org/10.3390/s19214611