1 Introduction

The advances of wireless network technologies and mobile devices’ computational power have created a new technology to pay for products and services in any place and at any time you require. This new technology is called mobile payment or m-payment, and it is a key component for increasing confidence in mobile commerce [1, 2]. Mobile payments can be defined as the process of exchanging financial value between two entities using mobile devices to pay for a product or services [3].

Mobile payment schemes proposed in the literature [4–23] can be classified in three types [24]. The first type of schemes is based on credit/debit cards. These types of schemes require high computational power to verify the authenticity and integrity of payment information because many cryptographic operations are computed. For example, the schemes proposed in [5, 10, 14, 15, 18, 22, 23] compute many public key cryptography operations to validate the digital signature. The second type of schemes is based on direct mobile phone bill. These types of schemes require a connection with the background infrastructure, such as Global System for Mobile communication (GSM), Universal Mobile Telecommunications System (3G) or Long-Term Evolution (4G), to charge the total amount of the purchase in the users’ mobile phone bill. However, these types of schemes do not provide privacy because the mobile network operator or carrier knows the users’ transaction. For example, the scheme proposed in [9, 21] requires a Short Message Service (SMS) in order to the mobile network operator or carrier accept the transaction. The last type of schemes is based on mobile cash. The mobile cash is the digital representation of the paper cash, and it is issued and controlled by a trusted third party such as bank. Mobile payment schemes based on mobile cash [4, 6–8, 12, 13, 17] provide strong privacy with low computational power, and they are suitable for micropayments. In this paper, we focus on mobile payment schemes based on mobile cash.

A mobile payment scheme based on mobile cash contains three participants (customer, merchant and bank) and consists of four phases (withdrawal, purchase, payment and deposit) [25]. The main security requirements for such schemes are [26, 27]: confidentiality, mutual authentication, integrity, and anonymity. Moreover, in terms of performance the schemes should require low computational power, low storage capacity and low administrative cost. Although many proposals of mobile cash or electronic cash can be found in the literature, few of them [28–33] prevent the bank’s database grows very fast. However, these schemes do not take into consideration the authentication process among participants.

In order to contribute in the field of mobile commerce, we propose a person-to-person mobile payment scheme (P2PM-pay) based on mobile cash. The mobile cash is controlled by expiration date preventing the bank’s database grows very fast. The mobile cash’s design is inspired in the partially blinded signature scheme introduced in [34]. Moreover, the scheme considers the effective date and deposit date of the mobile cash as security parameters. Furthermore, the public key infrastructure is efficient in terms of execution time because the certificate path validation process have been improved in [35, 36].

The paper is organized as follows. In Sect. 2, we explain the architecture of P2PM-pay scheme. The mobile payment scheme is proposed in Sect. 3. We evaluate the proposed scheme in Sect. 4. Finally, conclusions are given in Sect. 5.

2 P2PM-pay: Architecture

In this section, we give an overview of technologies used in the design of P2PM-pay scheme.

2.1 PKI-enabled SIM Card

A PKI-enabled SIM card [15] is a SIM card integrated with the Wireless Identity Module (WIM) making possible the use of certificates. PKI-enabled SIM cards are suitable for computing a public key algorithm such as RSA, and it takes advantage of security mechanism. Technically, it allows the implementation of Wireless Transport Layer Security (WTLS) protocol [37] to provide end to end security communication in mobile devices. The PKI-enabled SIM card can store private/public key pairs.

2.2 Bluetooth

Bluetooth [38] is a wireless technology to interconnect mobile devices with each other or with other devices via point-to-point or point-to-multipoint links. This technology transfers voice, data and video in real time. The transmission area is omni-directional and its transfer rate is 1 Mbps. The maximum distance between the data origin (source) and receiver is around 10 m. Bluetooth technology transmits and receives on frequency band 2.45 GHz. Bluetooth technology is a key element in mobile commerce because it enables mobile devices to pay for products. According with results presented in [3], Bluetooth is a valid option for wireless communication in mobile payment schemes.

In our scheme, the communication is via Bluetooth between customers-merchants and customers-loading centre (e.g., kiosk or ATM machine).

2.3 Wireless Public Key Infrastructure (WPKI)

We use WPKI certificates and WTLS protocol [37] to provide mutual authentication and to establish a secure channel among all the mobile users in an open network [39], where the transmitted and received signals travel over the air. The authentication process using certificates requires that the customer and the merchant start WTLS protocol. Authentication using certificates implies the validation of certification paths [40].

A certification path is a chain of Public Key Certificates (PKCs) through which a user can obtain the public key of another one. The primary goal of a path validation is verifying the binding between the entity and his/her public key. Then the verifier must check the signature and validity of each certificate in the path to trust in the public key of the target entity. Validity of certificates implies to verify the expiration date of each certificate and their revocation status. A trust anchor is the Certification Authority (CA) verification key used by the client application as the starting point for all certificate validation. Thus, the path is traced from the verifier’s trust anchor to the CA key required to validate the target entity’s certificate. So, the certification path length is equal to the number of certificates in the plus one: a CA certificate per each intermediary CA and the target entity’s certificate. Since, the verifier knows and trusts the public key of his/her trust anchor, the trust anchor’s certificate is not included in the path.

Certificate revocation is the mechanism under which an issuer can revoke the binding between an entity and a public key before the expiration of the corresponding certificate. A certificate can be revoked because of the loss or compromise of the associated private key, a change in the relationship with the issuer, etc. The standard certificate revocation mechanisms are Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP).

Based on previous research [36, 41, 42], we design a WPKI in where the mobile devices require low computational power to perform the mutual-authentication process using WTLS. Figure 1 describes the structure of the WPKI. The structure defined has the following characteristics:

  1. 1.

    A governmental organization such as national bank or department of the treasure is the Root Certification Authority (RCA), and it is responsible for issuing certificates to banks.

  2. 2.

    Banks participate as Certification Authority (CA), and they are responsible for issuing certificates to customers and merchants.

  3. 3.

    The size of certificates for RCA and CAs are 473 bytes [40].

  4. 4.

    The size of certificates for customers and merchants are 425 bytes [40].

  5. 5.

    The certification path length is L = 1, when the customer and merchant belong to the same CA, and L = 2, when the customer and merchant belong to different CAs.

  6. 6.

    The verifier use OCSP to verify the revocation status of certificates.

Fig. 1
figure 1

Structure of the WPKI

Full size image

3 P2PM-pay

3.1 Participants

The mobile payment architecture includes the following entities:

  • Customer-person who owns a mobile device to pay for products.

  • Merchant-person or vendor machine that accepts mobile payments.

  • Bank-entity that dispenses and validates mobile cash, and deposits funds in the merchant’s bank account.

The notations used in this paper are given in Table 1.

Table 1 Protocol notation
Full size table

3.2 P2PM-pay Protocol

The proposed mobile payment scheme consists of the following phases: enrolment process, withdrawal process, payment process, and deposit process. Figure 2 describes the interaction among the participants, and Fig. 3 shows the transmitted messages among the customer, merchant and bank during the execution of the proposed scheme.

Fig. 2
figure 2

Mobile payment scenario

Full size image
Fig. 3
figure 3

Messages exchange during the execution of the proposed scheme

Full size image

3.2.1 Enrolment

In this phase, the customer and merchant must be registered by the bank in order to get the security parameters and be part of the system. The security parameters include a pseudonym identity and certificate. The process is as follows:

Step 1:

Customer and merchant disclose their personal information to the bank. Then the bank verifies the information. If the information is valid, the bank creates a bank account number BAN A for each one. Finally, the customer and merchant must deposit w euros, dollars or pesos in their bank account

Step 2:

The bank concatenates and hashes the user’s real name and identity number of SIM card using a one-way hash function to get the pseudonym identity \( \left( {PI = H\left( {RN\parallel ID_{SIM} } \right)} \right) \)

Step 3:

The bank computes the public \( \left( {d_{C} ,\;p_{C} ,\;q_{C} } \right) \) and private \( \left( {e_{C} ,\;n_{C} } \right) \) key pairs

Step 4:

The bank stores the users’ RSA public key pairs and certificate, and its public key in the PKI-enabled SIM card

Step 5:

The bank publishes a one-way hash function H()

3.2.2 Withdrawal

When customers want to obtain mobile cash, they need to establish a communication with an authorized loading centre such as kiosk or ATM machine. The communication between mobile devices and loading centre is via Bluetooth. The process is as follows:

Step 1:

The customers and authorized loading centre verify the identity of each other by means of WTLS protocol [40]. After the WTLS protocol finish, customers and authorized loading centre know the session key and cryptographic algorithm to encrypt messages

Step 2:

The customers carry out the following process:

  1. 1.

    CREATE \( v = \varDelta_{1} \parallel i \)

  2. 2.

    CHOOSE RANDOMLY \( S\; and \;R \;in \;Z_{n}^{*} \)

  3. 3.

    COMPUTE \( y_{i} = H^{i} \left( S \right) \)

  4. 4.

    COMPUTE \( h_{1} = H\left( {y_{i} } \right) \)

  5. 5.

    BLIND h 1 COMPUTING \( \propto \equiv h_{1} \times R^{{e_{C} *v}} \left( {\bmod n_{C} } \right) \)

  6. 6.

    SEND BAN C , ν, α to Bank

Step 3:

After the bank receives the message, it carries out the following process

  1. 1.

    VERIFIES format of v

  2. 2.

    VERIFIES i ≤ balance account

  3. 3.

    If both verifications are approved, the bank deducts w euros, dollars or pesos from customer’s bank account and stores the operation in its transactional history

  4. 4.

    SIGNS α COMPUTING \( \beta \equiv \alpha^{{d_{B} *v}} \left( {\bmod n_{B} } \right) \)

  5. 5.

    SENDS β to Customers

Finally, customers compute \( \varepsilon \equiv \beta R^{{d_{C} *v}} \left( {\bmod n_{C} } \right) \) and get their mobile cash \( \left( {y_{i} ,\,\varepsilon ,\,v} \right) \).

3.2.3 Payment

When customers want to pay for a product using mobile cash, they and merchants perform the following steps:

Step 1:

Perform the cryptographic operations required in WTLS protocol. After the protocol finalized, each participant can encrypt and decrypt messages

Step 2:

Merchants compute and sends the AEPO to customers. The process is as follows:

  1. 1.

    COMPUTE the AEPO. The AEPO includes the identification of the product, price, quantity, pseudonym identity of the merchant, transaction date, identification of the transaction, and total payment

  2. 2.

    COMPUTE H(AEPO)

  3. 3.

    SEND AEPO, H(AEPO) to Customers

Step 3:

After customers receive the message, they perform the following process

  1. 1.

    VERIFY format of AEPO

  2. 2.

    STORE the total payment information into the variable \( y_{TP} \)

  3. 3.

    COMPUTE \( y_{x} = y_{i} - y_{TP} \) such that \( H^{i - TP} \left( S \right) = y_{x} \)

  4. 4.

    COMPUTE \( h_{2} = H\left( {\varDelta_{2} \parallel \left( {y_{i} ,\varepsilon ,v} \right)\parallel y_{x} \parallel y_{TP} } \right) \)

  5. 5.

    ENCRYPT \( c \equiv \left( {\varDelta_{2} \parallel \left( {y_{i} ,\varepsilon ,v} \right)\parallel y_{x} \parallel y_{TP} \parallel h_{2} } \right)^{{e_{B} }} \left( {\bmod_{{n_{B} }} } \right) \)

  6. 6.

    SEND c to Merchant

3.2.4 Deposit

In this phase, the bank deposits the funds in merchant’s bank account \( \left( {BAN_{M} } \right) \). The merchant and the bank must perform the following steps:

Step 1:

After the merchants receive the payment information, they carry out the following process

  1. 1.

    SEND \( BAN_{M} ,\,\varDelta_{3} ,\,c \) to Bank

Step 2:

After the bank receive the deposit requirement, it performs the following process,

  1. 1.

    DECRYPTS \( \varDelta_{2} \parallel \left( {y_{i} ,\varepsilon ,v} \right)\parallel y_{x} \parallel y_{TP} \parallel h_{2} \equiv \left( c \right)^{{d_{B} }} \left( {\bmod_{{n_{B} }} } \right) \)

  2. 2.

    COMPUTES \( h_{2}^{*} = H\left( {\varDelta_{2} \parallel \left( {y_{i} ,\varepsilon ,v} \right)\parallel y_{x} \parallel y_{TP} } \right) \)

  3. 3.

    VERIFIES \( h_{2}^{*} {}_{ = }^{?} h_{2} \)

  4. 4.

    VERIFIES format of \( v \)

  5. 5.

    CHECKS Δ 2 ≤ Δ 3 ≤ Δ 1

  6. 6.

    VERIFIES ε COMPUTING \( \varepsilon^{{e_{B} v}} \equiv H\left( {y_{i} } \right)^{{d_{B} v}} \left( {\bmod n_{B} } \right) \)

  7. 7.

    VERIFIES \( y_{TP} \le i \)

  8. 8.

    SEARCHES \( v and y_{i} \) to prevent double spending

  9. 9.

    COMPUTES \( y_{i} = H^{TP} \left( {y_{x} } \right) \)

  10. 10.

    DEDUCTS y ′ i  = i − TP

  11. 11.

    DEPOSITS \( y_{TP} \) into \( BAN_{M} \)

  12. 12.

    COMPUTES \( h_{3} = H\left( {y_{i}^{'} } \right),\;\varepsilon^{\prime} \equiv h_{3}^{{d_{B} v}} \left( {\bmod n_{B} } \right) \;and \;c_{1} \equiv \left( {Notification,h_{3} ,\varepsilon^{\prime}} \right)^{{d_{B} }} \left( {\bmod n_{B} } \right) \)

  13. 13.

    STORES ν and y i

  14. 14.

    SENDS \( Notification = Accepted\; or\; \text{Re} jected,\;c_{1} \) to Merchant

Step 3:

After the merchants know the status of the deposit phase, they deliver the product and

  1. 1.

    SEND Notification = Accepted or Rejected, c 1 to Customer

Step 4:

After the customers receive the response message, they know the status of the transaction and have the remainder of mobile cash. The process is as follows

  1. 1.

    DECRYPT \( Notification,\;h_{3} ,\;\varepsilon^{\prime} \equiv \left( {c_{1} } \right)^{{e_{B} }} \left( {\bmod n_{B} } \right) \)

The customers get their remainder of mobile cash by means of \( y_{i}^{'} ,\;\varepsilon^{\prime},\;v \).

4 Evaluation

In this section, we analyze the performance, security and usability of the proposed scheme. Moreover, we compare P2PM-pay with related works in terms of performance, security and usability.

4.1 Performance Evaluation

In this sub-section, we present a performance analysis in terms of cryptographic operations executed by each participant in P2PM-pay. By means of this evaluation, we want to know the number of cryptographic operations computed by each participant. Moreover, we want to know the size of each message exchanged during each phase. We assume the use of SHA-1 [43] as hash function and each data size is 6 bytes.

The number of cryptographic operations computed by each participant is presented in Table 2. The cryptographic operations computed during the WTLS protocol are not considered in this evaluation. We suggest to readers review related works [36, 41, 44–48]. Table 3 shows the number and size of messages exchanged by each participant during the different phases.

Table 2 Computational cost in P2PM-pay
Full size table
Table 3 Messages exchange between participants
Full size table

Table 2 and Table 3 show the performance of the proposed scheme. The number of cryptographic operations is low for merchants because they must compute several transactions every day. On the other hand, customers compute many operations during the withdrawal phase, but in the payment and deposit phases they compute low cryptographic operations. The bank computes more cryptographic operations because it verifies the validity and legacy of mobile cash.

In order to know the energy cost of cryptographic operations, we computed the energy cost of each cryptographic operation computed by the participant during the P2PM-pay scheme. We assume the energy consumption presented in [23]. Figure 4 shows the differences among three symmetric algorithms and provides an overview of their implementation. Moreover, Fig. 5 shows the energy consumption of RSA algorithm.

Fig. 4
figure 4

Energy cost of symmetric encryption/decryption using DES, 3DES and AES

Full size image
Fig. 5
figure 5

Energy cost of encryption/decryption using RSA algorithm

Full size image

According with the results presented in Figs. 4 and 5, P2PM-pay is suitable for mobile devices because the number of cryptographic operations does not required high energy cost. The evaluation in terms of energy cost demonstrated that the cryptographic operations carried out by merchants do not required high consumption of energy. This point is very important because merchants can compute several times the protocol during every day, so the energy cost must be low. Although customers’ devices compute four cryptographic operations during the payment phase, the energy cost is very low. Because the bank has more resources than customers and merchants, it computes more cryptographic operations requiring more energy cost. In brief, the energy cost is available for mobile devices, and it is not a limitation.

4.2 Security Analysis

P2PM-pay offers robust security because the scheme provides mutual authentication, payment authorization, confidentiality, and integrity.

Authentication: Mobile payment schemes must offer the option to authenticate each participate to prevent the participation of illegal participant.

  • Mutual authentication. Customers and merchants use digital certificates to authenticate each other by means of WTLS protocol.

Integrity: Mobile payment systems must guarantee that sensitive information have not been modified by an attacker.

  • Protection against eavesdroppers. The communication among participants is secure against attackers because the information is encrypted using the secret master key computed during the WTLS protocol.

  • Protection against physical exposure. The PKI-enabled SIM card protects sensitive information (e.g., private key, seed, blind factor) from unauthorized access.

  • Protection of payment information. By means of one-way hash function participants of the transaction can detect any modification in the payment information.

Privacy: Mobile payment systems must avoid eavesdroppers have access to the sensitive information.

  • No disclosure of real name. Customers and merchants do not reveal their real name.

  • No disclosure of personal information in the payment phase. Customers do not share private information with merchants.

  • No disclosure of customers’ purchase. The bank does not know the products purchased by customers.

Non-repudiation: Mobile payment systems should avoid refuting operations.

  • Prevent the rejection of the withdrawal. Customers are authenticated by the bank through their certificate. In addition, the bank stores the operation in the transactional history.

  • Prevent the rejection of the payment. The bank verifies the authenticity of the mobile cash before the merchant deliver the product.

Fraud detection: Mobile payment systems must detect any attempt of fraud.

  • Detection of double spending attack. The bank verifies the mobile cash in each transaction.

  • Detection of forgery attack. The seed of hash chain is known only by the consumer, nobody can create two equal y i .

  • Detection of illegal user. When a customer starts a commercial transaction with a merchant, they must exchange certificates and each participant can determine whether the certificate is valid or not.

4.3 Usability

In this sub-section, we evaluate P2PM-pay from the following factors [49]: cost, convenience and commercial scenario. Table 4 summarizes the common factors that influence in the success of mobile payment systems.

Table 4 Evaluation criteria for successful mobile payments
Full size table

P2PM-pay scheme is feasible for person-to-person and real point of sale scenarios because the computational cost, energy cost and messages exchange for each participant are very low. Moreover, the communication among entities does not require extra cost. Furthermore, customers and merchants can establish a secure communication wherever and whenever they want. Finally, the mobile cash’s validation is carry out by the bank. This type of mobile payment is useful for small stores.

4.4 Comparisons

We compare P2PM-pay with other mobile payment schemes based on mobile cash [8, 13, 28–30, 34]. We summarize the functionality of our proposal with others in Table 5.

Table 5 Comparisons between P2PM-pay and others
Full size table

The first characteristic of comparison is the effective date which represents the date of payment. This characteristic is incorporated in [29], [30] and P2PM-pay. By means of this characteristic customers and banks controls the spending of mobile cash. The second characteristic is the expiration date which represents the date of validity of each mobile cash. The expiration date is used by the bank to delete mobile cash with invalid date. This characteristic is included in [8], [34] and P2PM-pay. The third characteristic is the deposit date which represents the date when the merchants receive the payment in their bank account. This characteristic is included in [8], [13] and P2PM-pay. At this point, P2PM-pay is the unique scheme which includes the three characteristics related with the date.

In terms of security, P2PM-pay provides anonymity, integrity, mutual authentication, non-repudiation, and privacy as explained in [26, 27]. As a consequence, the scheme is secure against eavesdropping and malicious users. Security is the main requirement for mobile payments because the information exchange among participants is money, and participants do not want to lose money. The number of cryptographic operations is very similar to related works [8, 13, 23, 30–32] which means that P2PM-pay is efficient in terms of processing time.

5 Conclusions

In this paper, we have proposed a practical mobile payment scheme for person-to-person scenario which contributes in two aspects. First, the mobile cash prevents the bank’s database grows uncontrolled by means of the expiration date providing better performance during the verification process. The expiration date is added to the mobile cash using concatenation operation and partial blind signature scheme introduced by Abe and Fujisaki. The second aspect is related with the wireless public key infrastructure (WPKI). In P2PM-pay the WPKI provides an efficient certification path validation reducing the computational cost and making feasible the adoption of digital certificates. In brief, the computational cost to compute the mobile cash is low and easily applied to mobile devices because it is based on hash chain and one digital signature operation, and the adoption of digital certificates is feasible under the WPKI proposed.

From security point of view, P2PM-pay achieves the essential security requirements. The scheme provides anonymity to customers during the withdrawal and payment phase. Although customers and merchants exchange digital certificates, their identities are not exposed. The payment information does not contain data about the product; as a consequence, the bank does not obtain information about the customers’ habits. The communication among participants is encrypted avoiding eavesdropping.