A Novel NFC-Based Secure Protocol for Merchant Transactions

The unprecedented growth of mobile applications promoted the usage of these mobile applications for payments. The current research works in mobile payments and commerce are prone to reverse-engineering attacks and lacked transport layer protection, so these research works do not ensure security. Therefore, such attacks on Mobile Payment Applications (MPA) will be successful, which leads to severe financial loss. To address these issues, we propose a secure framework incorporating a defense-in-depth approach for Near Field Communication (NFC) based mobile payment frameworks. Our defense-in-depth approach has three levels, i.e., Defense at hardware, mobile application, and communication level. We have proposed a NFC based Secure Protocol for Mobile Transaction (NSPMT) protocol and successfully verified a mobile payment protocol with BAN (Burrows, Abadi, and Needham) logic and Scyther tool, and our proposed protocol overcome multi-protocol attack, RAM (Random Access Memory) scrapping attack, DOS (Denial Of Service), DDOS (Distributed Denial Of Service), and Phlashing attacks. Our proposed mobile Payment system overcomes the known mobile application vulnerabilities, including Heartbleed and ROBOT (Return Of Bleichenbacher’s Oracle Threat). Our proposed protocol ensures all the security properties and the energy and communication cost and computational cost are far less than the existing works in the literature. Finally, we have successfully implemented our protocol using kotlin language in Android Studio, with two Mobile Payment Applications (MPA) and POS Payment Application (PPA), Elliptic Curve Digital Signature Algorithm (ECDSA) is used and Advanced Encryption Standard (AES) with GCM (Galois/Counter Mode) mode is used for encryption and decryption of Customer Payment Data at MPA and PPA.


I. INTRODUCTION
The unprecedented growth of smartphones promoted mobile payment services based on mobile applications as consumers are adopting cashless payments. Information and communication technology (ICT) is widely used all around the globe [32]. With the comfort and acceptance of NFC smartphones, merchants encourage consumers for NFC based proximity payments. Berg Insight predicts that the exports of Point Of Sale (POS) based on NFC will be 4.1 million by 2022 [19]. MPAs are playing a vital role in mobile payment frameworks. MPAs are not as trustworthy as the intruders can tamper the MPA, so there is a need to strengthen the The associate editor coordinating the review of this manuscript and approving it for publication was Liang-Bi Chen .
MPA. As per our knowledge, there exists no solution to overcome the issues highlighted in the existing mobile payment research works. Ninety-eight percent of the mobile applications are reverse-engineered, and eighty-three percent of the mobile applications lacked transport layer security. Security and privacy of mobile transactions is the major hindrance to wide-spread adoption of these services. Therefore, such vulnerabilities in MPA will hinder the adoption of mobile payments. So security should be included and incorporated in the design at every phase. The main contributions of this work are: a) We propose a NFC based Secure Protocol for Mobile Transaction (NSPMT) incorporating a defense-indepth approach at three levels, i.e., Defense at hardware, mobile application, and at communication levels.
b) The proposed payment framework overcomes RAM scrapping attack, DOS, DDOS, and Phlashing attacks. c) MPA in our proposed payment framework overcomes the Heartbleed and ROBOT mobile application vulnerabilities. d) We propose a secure POS-based payment protocol and the proposed payment protocol is successfully verified with BAN logic and Scyther tool. e) The energy and communication cost and computational cost of our protocol are far less than the existing works in the literature. f) Proposed protocol was implemented using kotlin language in Android Studio.
The remaining article's organization is as follows: In Section II, we provide background and preliminaries on NFC, UICC (Universal Integrated Circuit Card), Hardware Security Module (HSM), and MPA. In Section III, we discuss the related work in the realm of secure proximity payments based on NFC. Section IV proposes a Secure Mobile Payment System based on NFC incorporating a defense in the Depth approach at the secure elements level and payment application level. Section V provides the formal verification of the proposed protocol. Section VI includes security analysis. Section VII presents the implementation and performance analysis of the proposed protocol, and Section VIII provides the conclusion of the paper.

II. BACKGROUND AND PRELIMINARIES
Customer possesses UICC in a smartphone, Merchant is an entity which sells goods or services and possesses a HSM, Bank is the financial institution of both the Customer and Merchant, MNO provides mobile network connectivity and updates Over The Air (OTA). PG acts as an adjudicator, containing evidence repository and provenance repository. Bank and Payment Gateway (PG) is an integral part of a secure private banking network that securely exchanges messages without encryption. Customer's anonymity is ensured by Traceable anonymous certificate (TAC), MPA is in the UICC of the smartphone, MPA shares a symmetric key between the Bank (B) and the Customer (C), POS Payment Application (PPA) shares a symmetric key between the Bank (B) and the POS. NFC is a technology very much compatible with the technologies used in transport and proximity payments. It is a high-frequency radio standard helping in exchanging wireless data within a range of 10 cm. NFC is compatible with ISO/IEC 14443 standard cards and readers and also with NFC enabled smartphones. According to GlobalPlatform [11] a Secure Element (SE) is a tamper-resistant hardware device which hosts applications. ETSI project smart card platform (ETSI EP SCP) standardized UICC, a universal platform for smart card applications. UICC hosts different mobile applications and allocates separate security domains for each application, governed by the Application Owner (AO). Card's Operating System (COS) of the UICC enforces firewalls among applications restricting applications from interfering with the working of other applications. As defined by Payment Card Industry (PCI) [17], HSM provides secure cryptographic services by implementing cryptographic logic, algorithms and processes [17]. Wireless Public Key Infrastructure (WPKI) ensures all the security properties, but the implementation of WPKI in the smartphone's memory is dangerous as the malware compromises cryptographic keys. UICC can generate and securely store the client's credentials, which includes private keys and X.509 certificates. In addition to these, digital signatures are also generated securely in UICC. All the entities in the framework trust certification Authority (CA) as it plays the role of a Trusted Service Manager (TSM) and adjudicator and its regular functions, including issuing certificates. Registration Authority (RA) verifies the entities' credentials involved in the ecosystem. The Bank acts as a RA in our proposed mobile payment framework. OCSP (Online Certificate Status Protocol) is an integral part of CA which updates the status of the revoked and compromised certificates. White Box Cryptography (WBC) is used to securely store symmetric keys and execute the symmetric encryption in MPA. UICC hosts Mobile Payment Application (MPA); MPA works with remote and NFC proximity mobile payments. It stores the keys and executes symmetric encryption using White-Box Cryptography (WBC). MPA is protected by PIN and biometric. Point Of Sale (POS) contains the HSM, which helps store cryptographic keys and execute cryptographic calculations. HSM is a Common Criteria EAL (Evaluation Assurance Level) 5 certified device ensuring the keys' security with effective, secure key management. HSM hosts PPA, PPA works with only NFC based payments, and it also stores the keys and executes symmetric encryption using WBC. PPA is protected by PIN and biometric. [1] proposes a cloud-based mobile payment mechanism, it claims security, anonymity, fairness, and the reduction of computational cost. After critically reviewing, we found the following limitations in [1] a) There is no clarity on how the client or customer interacts with the cloud. [2] proposes an extended version of the NFC cloud Wallet, where SE authenticates customers, but the cloud stores customer's payment information. Following are the limitations in [2] a) There is no clarity on how the cloud ensures the security of the payment information. b) There is no clarity on how the client or customer interacts with the cloud.

III. RELATED WORK
Isaac and Zeadally (2012) [3] proposes a payment gateway centric model for a anonymous secure payment mechanism. anonymous in a payment gateway centric model. Client and merchant exchange transaction data through a payment gateway. But the proposed work has the following limitations a) The client can deny Payment information as the generation of Payment information is anonymous. [4] proposes an efficient three-party authentication protocol based on ECC (Elliptic Curve Cryptography) algorithm in mobile commerce. It claims to have fewer computation and communication costs. [5] proposes an authenticated encryption scheme based on ECC algorithm. [6] proposes a mechanism for mobile electronic transactions based on cloud computing claiming that the client and merchant do not require a shared symmetric key. The following are the drawbacks of the proposed mechanism.
a) There is no clarity about the role of the Trusted Authority (TA) b) There is no clarity on how the client securely stores his credentials and payment information in the personal cloud. c) There is no clarity on how the Merchant and Bank securely store their credentials and their transaction data in the public cloud. [23] proposes a protocol for mobile payments based on NFC by making use of SE. [24] proposes a new communication network that connects banks with its client's mobile phones. It claims that it ensures security without compromising efficiency. The proposed work has the following limitations: a) There is no clarity on how the Bank ensures security. [5] proposes an e-payment system that is vulnerable to impersonation attacks. [25] Overcomes the shortcoming of [5] by proposing an improved authenticated encryption and e-payment schemes. It claims that the schemes are more robust and more lightweight than [5]. [26] proposes an offline mobile payment protocol which is compatible to EMV with mutual authentication using the reverse hash chain technique. [27] proposes an EMV-compatible payment protocol in order to overcome the risk in transactions. Communications security is ensured between a card and a card reader in order to overcome eavesdropping on sensitive data. In addition to these, the protocol resists impersonation attacks and avoids the security threats in EMV. [28] proposes a mobile payment protocol which is lightweight and based on Short Message Service (SMS) that ensures information security and fair exchange properties. The proposed protocol is formally proven using BAN logic and the Scyther tool. [29] proposes a lightweight and secure NFC mobile payment protocol ensuring information security and fair exchange properties for sales transaction processing. The proposed protocol is formally proven using both Burrows, Abadi, and Needham (BAN logic) and the Scyther tool. [30] proposes a secure operational model for mobile payments based on a service-oriented architecture based on a two-dimensional barcode as the payment certificate. Authors of [31] proposed a NFC mobile payment protocol based on public key cryptography.
All the research works discussed in this section are vulnerable to reverse-engineering, DOS, DDOS, Phlashing attacks, lacked transport layer protection and does not ensure end to end security and evidence cannot be guaranteed in case of security breaches. All the research works (except [28] and [29]) discussed in this section are vulnerable to multi-protocol attacks.
[1]- [6] and [23] protocols are not formally verified. All the research works discussed in this section are vulnerable to RAM scrapping attack and VOLUME 10, 2022 fails to withstand Heartbleed and ROBOT vulnerabilities. As per our knowledge, we are the first to address Heartbleed and ROBOT vulnerabilities, RAM scrapping attack. [4]- [6], [23], [5] and [26]- [30] protocols cannot withstand insider attacks. [25]- [30] protocols cannot withstand stolen smart card attack, parallel session attack, physically stolen device attack and unauthorized key computation attacks. [4]- [6], [23], [24] and [25]- [30] protocols do not ensure communication and application security. Except [23], no work has implemented its proposed protocol in real-time. Table 1 shows the list of abbreviations used in this paper.   Figure 2 depicts the proposed defense-in-depth approach for the mobile payment system.

1) DEFENSE AT HARDWARE LEVEL
The manufacturer of UICC and HSM requests CA for a Chip certificate. CA issues a chip certificate to the SE and HSM chip. EAL4+ (Evaluation Assurance Level 4+) certificate is issued by CA for integrated circuit (IC) chip. CA also issues a certificate to the operating system (OS), which excludes applications. In our proposed mobile payment system, customers possess UICC in the smartphone as a SE, and the merchant uses the Hardware Security Module in its POS. WPKI ensures end to end security as UICC and HSM have WPKI functionality to generate and securely store client's and merchant's credentials, including private keys and X.509 certificates. In addition to these, digital signatures are also generated securely in UICC and HSM. UICC and HSM host several mobile applications, either from the UICC and HSM issuer or from other service providers, each application defines and administers its application. UICC and HSM allocate separate security domains for each application, governed by the Application Owner (AO). Respective Operating Systems enforces firewalls among applications restricting applications from interfering with the working of other applications. MPAs are customized by the Application Issuer using Over The Air (OTA) technology. So UICC and HSM cannot be tampered and securely protects the private keys and payment applications. Bank (B) acts as a Registration Authority (RA); it registers all the Customers (C) and Merchants (M) and helps in getting certificates from Certification Authority (CA). CA maps the certificate identity and chip certificate to the uniqueness of the entities in the ecosystem. The Bank contains the database of the customers and merchants.

2) DEFENSE AT APPLICATION LEVEL
MPA is in the UICC of the smartphone; MPA shares a symmetric key between the Bank (B) and the Customer (C). PPA is in the HSM of the Merchant's POS. PPA shares a symmetric key between the Bank (B) and the POS. Using the procedure given in (Kungpisdan et al., 2003) [8], the generation of new session keys is possible using hashing algorithms given in (Kungpisdan et al., 2003) [8].
This system uses WBC [7], which ensures the security of secret and session keys in the MPA. The Bank updates the keys in the MPA of SE on the smartphone. The symmetric key is protected in the payment applications using WBC. The adversaries cannot extract the key from the payment application despite knowing the encryption algorithms and key lengths. WBC provides Trusted Execution Environment (TEE) in the payment application. The Bank is the Application Provider (AP) of both MPA and PPA, and CA verifies the authenticity of both MPA and PPA. MPA and PPA overcome reverse engineering attacks by binary code obfuscation, flow relocation, stripping debugging information, and by encrypting strings and resources in the code. In addition to these, the Bank enforces Self-Signing Restriction on MPA and PPA, and the Bank's private key attests the code of the MPA and PPA, so MPA and PPA overcome reverseengineering attacks.

3) DEFENSE AT COMMUNICATION LEVEL
Our proposed Mobile Payment framework's security does not rely on network layer security as it is susceptible to eavesdropping attacks. All the entities involved in our proposed Mobile Payment framework use CA-signed certificates. The entities involved in the ecosystem implement certificate pinning, ensuring communication security. Bank detects DoS attacks from activity profiling, change-point detection, and wavelet-based signal analysis detection techniques. The Bank only communicates with the legitimate subscribers. Bank only establishes a secure connection with the legitimate subscribers by establishing a secure channel with the payment application in UICC of smartphone and HSM of POS using TLS (Transport Layer Security) protocol at the communication layer. Bank updates the security of the payment applications Over The Air (OTA) by patch management.

B. GENERATION AND ISSUANCE OF CERTIFICATES BY THE CA
This section explains the generation and issuance of X.509 certificates to merchants, customers, and banks. Figure 3 depicts the generation and issuance of certificates by the CA. CA issues the following certificates: a. updates the status of the revoked and compromised certificates. We propose three algorithms in this sub-section; they are Algorithm 1: Generation and Issuance of X. 509 certificates to the customer by the CA, Algorithm 2: Generation and Issuance of X. 509 certificates to the merchant by the CA, and Algorithm 3: Generation and Issuance of X. 509 certificates to the Bank by the CA.

C. PROPOSED SECURE MOBILE PAYMENT PROTOCOL
Our proposed, secure mobile payment protocol has three steps. Figure 4 depicts the steps involved in the proposed Mobile Payment protocol. Table 2 shows the notations used in the proposed protocol.
Step 1: Customer (C) selects and collects all the items in the store and comes to the POS for paying the bill. The merchant calculates the bill amount and displays it at the counter. Merchant shows a unique Merchant ID (MID) at the counter for the convenience of the customers.
The customer encrypts the filled-in MPA with the symmetric key shared between the Customer (C) and the Bank (B). Customer (C) sends the encrypted message to the POS using NFC link. Step

1) SECURE EVIDENCE PRESERVATION MODULE (SEPM)
SEPM is a part of the Payment Gateway (PG); its function is to collects and stores the evidence in the evidence repository. PG collects the evidence from transaction data, registry logs, and timestamps with the Network Time Protocol (NTP) from network logs. It stores the evidence in the repository according to transaction identity.

2) SECURE PROVENANCE MODULE (SPM)
A provenance-aware storage system (PASS) provides search for provenance as it a depository which manages the storage. PASS helps SPM in finding and storing the evidence.

V. FORMAL VERIFICATION OF THE PROTOCOL A. FORMAL VERIFICATION OF THE PROTOCOL USING BAN LOGIC
A security protocol exchanges messages which are encrypted using cryptographic mechanisms (Muhammad et al., 2006) [12]. BAN logic [13], [14] analyzes the security of the protocol.
Assumptions for the analysis and verification of the proposed protocol (a) Assumptions about keys and secrets: 'X' is a set of entities having {C, POS, and B}. CA issues certificates to all the entities involved in the system, and all the entities have their keys (AS1, AS2). Step 3: Enrolment Activation Code (EAC) is issued by the CA to the customer based on the recommendation of MNO.
Step 4: After generating his keys (both public key and private key), the customer sends an encrypted (with the public key of the CA) message containing his public key, along with EAC and a digital signature generated on the EAC using the private key of the customer.
Step 5: CA decrypts the received message, checks the EAC, and verifies the digital signature generated on EAC.
IF Step 3: Enrolment Activation Code (EAC) is issued by the CA to the merchant based on the recommendation from the bank.
Step 4: After generating his keys (both public key and private key), the merchant sends an encrypted (with the public key of the CA) message containing his public key, along with EAC and a digital signature generated on EAC by the private key of the merchant AS2. X ∈ {C, POS and B}X believes K ca → CA). All the entities in the system possess the public key and x.509 certificate of CA.

(b) Assumptions about freshness:
These assumptions specify the freshness of quantities. AS3. POS believes freshness N C ; if POS sees quantity N C in a message, the POS can conclude that it is a replay message.
AS4. B believes freshness N POS ; if B sees quantity N POS in a message, the B can conclude that it is a replay message.
(c) Assumptions about Timeliness: All the entities involved believe that the nonce generated by them are unique and fresh. These assumptions are about the certificate's validity and timestamping.
AS5. T C is the timestamp generated by the C, ensuring timeliness.
AS6. T POS is the timestamp generated by the POS, ensuring timeliness.
(d) Assumptions about trust: The following assumptions are about the trust levels of all the entities.
AS8. ∀ belief X, CA believes (Bank controls (X believes Y)). CA trusts the Bank that Bank to relay the Bank's beliefs.
Verification of our proposed Protocol using BAN logic: Step  Step 3: Bank sends its credentials to the CA; after successful verification of the Bank's credentials, the CA generates and issues enrolment activation code (EAC) to the Bank.
Step 4: After generating his keys (both public key and private key), Bank sends an encrypted (with the public key of the CA) message containing his public key, along with EAC and a digital signature generated on EAC by the private key of the Bank.
Step 5: CA decrypts the received message and checks the EAC, and verifies the digital signature generated on EAC. IF

B. FORMAL VERIFICATION OF THE PROTOCOL USING THE SCYTHER TOOL
Proposed protocol is written in Security Protocol Description Language (SPDL); SPDL is a language for the Scyther simulation tool [15] & [16]; it verifies the security of protocols. This tool defines the roles of the entities in our proposed system. All the entities involved in the framework experience three types of attacks; the first attack is integrity attack, the second is authentication attack and the last one is confidentiality attack.
Scyther is tool used in verifying, falsifying, and analyzing the security properties of a protocol. Table 2 maps security objectives with security properties. Table 3 shows the parameters used in the Scyther verification tool. Table 4 shows the outcome of automated security claims using the Scyther verification tool. It is the only tool which has the ability to verify multi-protocol attacks. Appendix presents the code used in NSPMT (NFC based Secure Protocol for Mobile Transaction) in SPDL. Attack Model: In our proposed system, we use Secure Elements in Customer (C), HSM in POS of Merchant (M), and Bank (B), so these devices cannot tamper, and the messages transmitted are encrypted, so all the security properties are ensured thereby, ensuring the end to end security.

VI. SECURITY ANALYSIS
This section provides the security analysis of the proposed protocol. Table 5 shows the comparative analysis of NSPMT with the related work. 1) Confidentiality: Data exchanged among the participants in the framework are encrypted using session keys thereby ensuring confidentiality. 2) Mutual authentication: WPKI is a part of both the device and MPA, which authenticates the entities using certificates. Bank personalizes Payment Applications (PA) in the Customer (C) and Merchant (M), i.e., the Bank shares a separate symmetric key with Customer (C) and Merchant (M), thereby ensuring mutual authentication. 3) Integrity: Intruder will not be able to access or modify the messages. In addition to this, the encrypted message also contains timestamps and nonce, ensuring timeliness and uniqueness properties. So, the intruder cannot modify the messages, thereby ensuring the integrity of the exchanged messages. 4) Accountability: Figure 4 depicts the steps involved in the protocol containing all the entities involved; PG (Payment Gateway) ensures accountability property, collecting evidence from the Bank. The proposed framework implements WPKI. Bank updates the MPA of the Customer and PPA of the POS Over The Air (OTA). PG maintains the Evidence Repository (ER) and Provenance Repository (PR), ensuring accountability property. So the proposed protocol provides accountability.

5) Defense in Depth: Our proposed framework incorpo-
rates protection in-depth at the SE level and payment application level. WPKI provides application security, and the TLS protocol provides communication security. If the symmetric key is compromised, bank updates the symmetric key in the payment application. 6) Overcomes Heartbleed and ROBOT Vulnerabilities: Heartbleed, and the recent ROBOT [9], [10]. Our proposed mobile payment system uses newer versions of TLS certificates signed by the CA. So our proposed mobile payment system overcomes these vulnerabilities.

7) Fake Terminal and Mobile Application: An intruder
cannot reverse engineer MPA and PPA as both (MPA and PPA) overcomes reverse engineering attacks by binary code obfuscation, flow relocation, stripping debugging information, and by encrypting strings and resources in the code, in addition to these Bank enforces Self-Signing Restriction on MPAs and PPAs and codes of these applications is attested by the Bank's private key, so our proposed mobile payment framework overcomes reverse-engineering attacks.

8) Tampering Configuration:
The workflow of the configuration file in MPA will be modified, so this attack will not be fruitful in our proposed mobile payment system as both MPA and PPA overcome this attack by flow relocation, stripping debugging information, and by encrypting strings and resources in the code, in addition to these Bank enforces Self-Signing Restriction on MPAs and PPAs and codes of these applications is attested by the Bank's private key, so our proposed mobile payment framework overcomes tampering configuration attack. 9) RAM Scraping: This attack is also known as memory scraping or memory parsing attack, which retrieves payment information and symmetric keys from the memory of MPA. RAM Scraping or Memory Parsing attack will not be successful from the SE or MPA of either the customer's smartphone or the HSM of the POS as SE and HSM are tamper-resistant. At the same time, MPA and PPA adopt WBC.

10) Dishonest Merchant:
If the Merchant tries to cheat the Bank or Customer by overspending or double-spending the customer's payment information, he will not be able to do so as the customer encrypts the message received with a symmetric key shared between the Customer and Bank. If the merchant tries to reuse the customer's message, he will not be successful because it contains timestamps and nonce generated by the customer. 11) Transaction Sniffing: Transaction sniffing is not possible in our proposed mobile payment protocol as our proposed protocol ensures communication and application security. 12) POS Security: HSM is a tamper-resistant hardware device that protects the merchants' credentials, ensuring protection against hardware attacks. POS's HSM hosts PPA, PPA contains a symmetric key shared with the Bank. HSM securely stores its credentials (private key) and cannot be accessed by unauthorized entities. 13) Payment Secrecy: WBC and symmetric keys provide payment secrecy. 14) Multi-Protocol Attack: It is a type of attack in which one protocol interferes with the functioning of the other protocol. This attack will not be successful in our proposed system as we have successfully verified our proposed protocol using the Scyther tool. 15) Man-in-The Middle Attack: Data exchanged among the participants in the framework are encrypted using session keys, in addition to this message also contains timestamps and nonce thereby overcoming Man In The Middle Attack. 16) Replay Attack: Our proposed framework overcomes the Replay attack as the participants in the framework are encrypted using session keys, in addition to this message also contains timestamps and nonce. 17) Impersonation Attack: Our proposed system overcomes impersonation attacks. The attacker fails to generate session keys. 18) Parallel Session Attack: Intruder will not be successful in starting a parallel session in our proposed framework. The Bank establishes a secure tunnel based on TLS protocol and by certificate pinning. In addition to this, encryption ensures application security using the AES algorithm. So, the Attacker/Intruder cannot have a new parallel session in our proposed framework. In addition to these, Scyther verifies our proposed protocol. So, our proposed framework overcomes or withstands parallel session attacks.

19) Physically Stolen Device Attack:
If an adversary steals a smartphone or POS, he will not be able to extract customers' or merchant's credentials as the smartphone does not store Customer' information.

20) Resistance against Unauthorized Key Computation:
Attacker will not be able to compute session keys as the attacker does not have private keys of the Bank, Customer, and POS.

21) Resistance Against Stolen Verifier Attack: An
intruder cannot get any relevant information or verifier from MPA, PPA, SE, and HSM as these implement WPKI and WBC. So our proposed system is safe against stolen verifier attack.

27) Formal Verification:
Proposed payment protocol is successfully verified using BAN logic and Scyther tool, so our protocol overcomes all the known attacks.

VII. IMPLEMENTATION AND PERFORMANCE ANALYSIS OF THE PROPOSED PROTOCOL
This section highlights the implementation details and performance analysis of the proposed protocol. VOLUME 10, 2022

A. IMPLEMENTATION OF THE PROPOSED PROTOCOL
We Implemented ECDH Key exchange and AES encryption for proximity payments using Kotlin language in Android Studio (Kotlin interoperates fully with Java). There are two applications MPA and PPA, in our research work. ECDSA (digest algorithm used is SHA-256), an algorithm is used in generating digital signature, and the AES algorithm for encrypting messages. Kotlin language implements our protocol in real-time. Kotlin interoperates fully with Java. We created an EC key pair (NIST P-256 aka secp256r1) at customer-bank and merchant-bank by using ECDH, we created a shared AES secret key. AES with GCM (Galois/Counter Mode) used for encryption and decryption of Customer Payment Data at MPA and PPA. Table 6 shows the environmental parameters used in the implementation of the proposed protocol. Figure 5 depicts the ECDH key exchange process between the Customer's MPA and the bank server. Using the customer's private key and Bank Server's public key, the Customer's MPA generates a shared AES key. Similarly, the bank server also generates a shared AES key by using the customer's public key and the bank server's private key. Figure 6 depicts the ECDH key exchange process between the Merchant's PPA and the bank server. Using  the merchant's private key and Bank Server's public key merchant's MPA generates a shared AES key. Similarly, the bank server also generates a shared AES key using the merchant's public key and bank server's private key. Figure 7 shows the user authentication screenshot. To complete the payment, the customer needs to authenticate either through PIN or Fingerprint. Only after successful authentication, the customer is allowed to use MPA. Figure 8 shows the MPA screen containing merchant ID, merchant name, and total bill amount, which is encrypted and sent to POS via NFC. Figure 9 shows the screen containing merchant transactions, customer ID, and customer encrypted payment data. After successful payment completion at the bank server, this screen receives a successful message from the bank server, shows success status to the merchant, and sends a successful message to the customer MPA. Figure 10   shows the plain and encrypted transaction and payment status from PPA. Our implementation details and code are here: https://github.com/ShaikShakeelAhamad/merchantcustomer-payment B. PERFORMANCE ANALYSIS OF THE PROPOSED PROTOCOL Table 8 presents the computational cost analysis of the proposed scheme against related schemes. The notations used in the table are TH and TS, which denotes the complexity of time for computing the one-way hash function (TH) and symmetric encryption/decryption (TS) operation.
The performance analysis shows the effectiveness of the proposed protocol as it utilizes one-way hash and symmetric encryption/decryption functions, both of which are the least  expensive than other cryptographic functions. As presented in [5], the time complexities (in seconds) are TH = 0.0004 and TS = 0.1303. One ECPM (Elliptic Curve Point Multiplication) is equal to 0.001015 seconds from [22]. Clearly, our proposed work shows better performance (see Figure 11). Table 8 compares our proposed protocol with the related works in terms of consumption of energy. According to [5] the consumption of energy to generate AES encryption/decryption (ES) is 1.21 Micro Joules/byte and for generating hash code (EH) using SHA-1 algorithm is 0.76 Micro Joules. The energy consumption of One ECPM (Elliptic Curve Point Multiplication) is equal to 578.55 Micro Joules from [22]. As shown in the table, our work is better than other works ( Figure 12).