1 Introduction

Today, mobile payments are a proper alternative to traditional payment methods. Analysts have dubbed the event "the death of cash" [1].

Mobile payment systems allow individuals or organizations to do secure financial transactions with other people through a wireless network using mobile devices. Each mobile payment system includes four principal entities: the customer, the merchant, the merchant’s financial institution (as the acquirer), and the customer’s financial institution (as the issuer). Also, the mobile payment system can include an additional entity called the payment gateway, which acts as an intermediate for payment-clearing purposes between the acquirer and the issuer. These entities communicate with each other using an internet access service. Communications among the issuer, the acquirer, and the payment gateway take place over the private banking networks, and the security of these communications is provided using cryptographic mechanisms [2].

Mobile payment systems based on symmetric cryptography use a shared secret key. For this reason, the robustness and efficiency of these algorithms depend on the key length used and secure transmission of keys between both sides of the transaction. Also, symmetric cryptography cannot provide non-repudiation and authentication requirements if an attacker is successful in compromising the symmetric key, then both customer and merchant get exposed and all the payment transactions encrypted with that key are exposed [3, 4].

To avoid the above issues, new generations of mobile payment systems are making extensive use of public key cryptography. These systems use a pair of keys (a public key that is published and a private key that remains hidden) for both sides. Therefore, there is no need to share the secret key between the customer and merchant before the secure connection. Also, for providing non-repudiation and authentication, these algorithms use the digital signature [4].

However, the main problem in developing mobile payment systems based on public key cryptography is the deployment and management of infrastructure to implement the authenticity of cryptographic keys. For solving this problem, the Public Key Infrastructure (PKI) is used, in which users' digital certificates are issued by a Certificate Authority (CA). However, the use and management of PKI are often considered costly; because it includes revocation, storage, distribution, and verification [5].

Fortunately, IBS systems have been introduced to solve digital certificate issues in the public key cryptosystem [6]. All user keys in these types of systems are generated based on their identity information (such as email address); for this reason, a certificate is not required to prove the authenticity of users. However, ID-based mobile payment systems have a key escrow problem; because users' private keys are issued by a third party called the Key Generation Center (KGC), KGC can find all the user's confidential information or forge the user to generate a valid signature based on his identity [5].

In addition to security issues, mobile devices used in mobile payment systems are facing many challenges in their resources such as low battery life, limited storage space, and low bandwidth. Limited resources significantly prevent the improvement of service qualities [7].

Therefore, a secure and efficient mobile payment system should address the security issues mentioned above; also, the computational overhead on mobile devices should be minimized and appropriate communication technology should be used among these devices to perform payment transactions. To achieve this, the present research study offers a mobile payment system with the ability of tracing and revocation of malicious users through an identity-based signature scheme wherein the issues related to digital certificates are resolved. In this proposed protocol, the keys chosen by the users for transactions are used to address the key escrow problem. The ProVerif automated tool is also used to ensure the security of the proposed protocol against known active and passive attacks. In order to reduce computational overhead on mobile devices, some calculations pertinent to the time key update and signature verification are outsourced to the cloud server. The scheme also demonstrates a suitable communication technology between mobile devices for payment transactions.

The next sections of this article are as follows: In Sect. 2, earlier works are recalled. In Sect. 3, the background of the proposed scheme is illustrated. In Sect. 4, the proposed scheme is presented. In Sect. 5, the proposed protocol is compared and evaluated with other similar protocols, and in Sect. 6, a general conclusion is given.

2 Related works

So far, the issue of mobile payment security has been discussed by many authors. Here is an overview of previous works in this area. It should be noted that requirements for security, such as identification, authentication, security message protocols, messaging and data cryptography, differ for each technology generation and each payment scenario [8]. Therefore, in order to evaluate mobile payment systems, these should be considered.

One of the oldest mobile payment systems could be the proposed system by Chaum [9] in 1983, based on blind signatures. In this solution, the requester could get a valid signature on the message without showing the message content to the signer. Later, in 2003, Chang and Lai [10] presented a date-attachment blind signature scheme for e-cash. Juang [11] also introduced a pre-paid e-cash system for date attachment based on blind signature in 2007. Unfortunately, blind signature methods are weak against a chosen text attack due to the use of the RSA algorithm [12, 13].

In 2007, Bisel [14] examined the role of the Secure Sockets Layer (SSL) in cybersecurity. To this end, it outlined the strengths and limitations and weaknesses of SSL. Then, SSL and Internet Protocol security (IPsec) were compared and evaluated. Guan [15] in 2009 reviewed a Secure Electronic Transaction (SET)-based payment system and concluded that the protocol would lead to more security and efficiency in the payment transactions. In 2012, Frisby et al. [16] analyzed the security of smartphone point-of-sale systems. They showed that all payment applications using Transport Layer Security (TLS) are protected against an attacker on the network. Leu et al. [17] reviewed SSL and SET in 2015 and proposed a Secure Mobile Commerce System (SMCS) to improve these protocols.

SSL and SET use both public key and private key as a basis for securing the message exchange process. In payment transactions using SSL, it’s just enough for a person to send the merchant, card number, expiration date, and other information. However, at SET, the customer and merchant must apply for the certificate so that they can receive the electronic certification of SET and its software from the card-issuing bank. Then, they use the software to complete a transaction online. Therefore, in SET, unlike SSL, both sides of the transaction can authenticate each other. Also, the SET can protect consumer’s credit data, since the merchant needs only a consumer’s SET credential before it can bill the card-issuing bank.

As customers and merchants apply for a SET certificate, credit card information of the user is stored on a hard disk. Also, SET spends a lot of time for computing asymmetric keys (keys for encryption and decryption) to improve security, resulting in an unpleasant experience of mobile commerce for users. To address these issues, the SMCS proposes a credit card in which a dynamic authentication code has been replaced with credit card information so that merchants cannot know the number of credit cards and their details. To establish a secure channel is required in mutual authentication and provide a secure wireless exchange of the messages, the SMCS uses a Data Connection Core (DCC) to connect the card-issuing bank and the client in before starting a wireless connection. It also provides confidentiality property by a two-dimensional stream cipher technique. Leo et al. simulated this protocol using Java. The most important simulation approach was that SMCS has very high computational overhead due to the use of various functions such as RSA, AES (Advanced Encryption System), and HMAC (Hash-based Message Authentication Code).

In 2015, Pelaez et al. [18] presented a Person to Person Mobile payment (P2PM-pay) scheme based on mobile cash. They also designed a Wireless Public Key Infrastructure (WPKI) to perform the authentication and user certificate revocation process.

In PKI-based schemes, the validity of each certificate is generally limited to one expiration date. Ideally, certificates are expected to be used for their entire validity. Unfortunately, there are situations in which a certificate must be revoked before its expiration date; for example, if the private key of a certificate is lost or exposed. So for such cases, a mechanism is required to revoke the certificate. For this reason, mechanisms such as Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) were introduced to revoke the certificate before its expiration date [19].

Generally, public key infrastructure is a security solution for mobile payments that requires a lot of computing overhead [20]. Wireless PKI designed by Pelaez et al. [18] uses the Wireless Transfer Layer Security Protocol (WTLS), which to some extent avoids the problems of traditional PKI (especially computing overhead on mobile devices). The system avoids the rapid growth of the bank’s database, since the expiration date is embedded into the mobile cash by partial blind signature during the withdrawal date, and the bank does not hold information about the operation. But because wireless PKI also uses certificate-based digital signatures, it imposes restrictions on users such as high bandwidth, network latency, and additional costs [2].

In [21] Isaac and Zeadally presented a payment protocol in a payment gateway centric model. All payments sent between entities of this protocol are transferred through the payment gateway. Therefore, customers do not directly communicate with the merchant and the anonymity of consumers is provided. In this protocol, symmetric cryptography is used to provide the confidentiality property, and the Message Authentication Code (MAC) is used to ensure the message integrity. This mechanism also fulfills the requirements of cloud computing, because the payment gateway can be used as a cloud service provider for mobile payments. However, this protocol does not provide the non-repudiation requirement and affects symmetric cryptographic issues, especially the key management problem. As a result, it is not suitable for mobile payments in cloud computing.

Yang and Lin [22] in 2016, proposed a similar mechanism to improve the Isaac and Zeadally protocol [21]. In this protocol, there is a payment gateway between the customer and the merchant, and the customer uses the anonymous identity to create payment information. Hence, the merchant does not know who is buying the goods. The customer’s bank also does not know what she is buying, since transaction information and payment information are protected by the one-way hash function. The customer’s bank generates the digital signature as a payment proof; thus, the non-repudiation requirement is provided. The scheme uses the RSA algorithm [23] to provide confidentiality; consequently, the key management problem is solved, but the key length is very high (less performance).

Qin et al. [24] in 2017 used the certificate-less signing scheme belongs to Huang et al. [25] in their protocol; This signature scheme is based on bilinear pairings, which provide requirements of non-repudiation, unforgeability and traceable messages transmitted. Also, the signature scheme of Huang et al. solves issues relating to certificate-based digital signatures and key escrow problems. Qin et al. combined the idea of outsourcing and certificate-less signature to reduce computational overhead on mobile devices. Also, to provide anonymity, they kept confidential the identity of the customer at all stages of the transaction; in this way, they transformed the customer’s real identity into two pseudo-identities using the tamper-proof device. This pseudo-identity is an ElGamal-type cipher-text in the Elliptic Curve Cryptosystem (ECC) [26] that remains secure against chosen-plaintext attacks.

In 2018, Liao et al. [27] reviewed the mobile payment protocol provided by Qin et al. [24]. Liao et al. described a colluding attack in Qin’s protocol which the customer and the untrusted cloud server can collude with each other and cheat the merchant. Hence, Liao et al. used hard computational assumptions to verify an outsourced signature for eliminating colluding attacks. Liao et al. also pointed out that the structure of Qin’s protocol and its structure was unreasonable since, in the signing algorithm of their protocol, a point over an elliptic curve is added with an element of a set, which is not to be defined. To solve this problem, Liao et al. defined two points over an elliptic curve for adding operation in calculating the signature.

The evaluation of the newest mobile payment systems is given in the Table 1. According to reviews, just in schemes [24, 27] has been solved the problems of managing digital certificates, and key escrow. However, even in these mobile payment systems, there is no possibility of revocation malicious users, and the security of these protocols in a formal manner is not guaranteed against known active and passive attacks. These protocols do not demonstrate the appropriate technology to communicate between mobile devices. Also, the executing time of the signature validation algorithms server-aided in these protocols is high.

Table 1 The evaluation of the newest mobile payment systems
Full size table

3 The background of proposed scheme

Mobile payment systems should provide the security properties unforgeability, non-repudiation, anonymity, traceability, and revocation of malicious users. They must be resistant to known active and passive attacks. Also, these systems must use a reasonable solution to communicate between mobile devices and minimize computational overhead.

For resolving the above issues, the proposed protocol uses an unforgeable IBS based on bilinear pairing. Because, among the various types of identity-based systems (such as quadratic residues, discrete logarithms, bilinear pairing, and lattice), systems that are based on bilinear pairing have lower computational overhead and more efficient [28]. This protocol also addresses the issues related to digital certificates and provides non-repudiation and traceability properties. In this scheme to resolve the problem of the key escrow, users choose the keys (which are not known by the KGC) for transactions. Additionally, the proposed scheme to protect users’ privacy uses the pseudo-identity method, and to provide key revocation uses a list contains the pseudo-identity of malicious users. The proposed system reduces the computational overhead of mobile devices by utilizing a cloud server and modifying system parameters and it uses the appropriate technology. The ProVerif automated tool is also used to verify the security of the proposed protocol against known attacks formally.

3.1 The architecture of the proposed scheme

In this section, the architecture of the proposed protocol is presented. The main drivers of mobile devices in this scheme that enables convenient and secure mobile commerce services are the following [29, 30]:

  1. 1.

    Mobile wallet application (such as Google Wallet) which is a program or service that allows users to store and control their shopping information, like logins, passwords, shipping address, and credit card details, in one central place

  2. 2.

    Mobile payment application for buying and billing

  3. 3.

    Internet access with 3G/4G broadband

  4. 4.

    Low computational overhead (high performance)

  5. 5.

    Multi-media contents from merchants to stir purchasing desire on the move, extending from mobile commerce players (such as eBay, Amazon, Google, and etc.)

In the proposed system by using near-field communication (NFC), the mobile device is able to provide the customer with information about products that she is currently observing. For example, a mobile device can identify product features including its ingredients content, its price, and its expiry date [31].

Generally, to communicate between mobile devices use well-known communication protocols that currently, NFC technologies are the leading form of mobile payment methods. Many organizations using mobile payment services are adopting NFC systems to replace credit cards. In addition, communication security has been enhanced by using standard techniques to enable NFC services. Google, Apple, and Samsung in order to replace credit card transactions have released new mobile payment services that most of these services operate based on the NFC standard [32].

The NFC technology allows peer-to-peer communication between NFC-enabled devices like NFC phone and NFC Point-of-Sales (PoS). NFC-enabled devices and contactless PoS terminals execute payment transactions at the range of a few centimeters using communication protocols that are based on Radio-Frequency IDentification (RFID) standards [33]. Figure 1 shows a type of mobile device that integrates with the NFC technology.

Fig. 1
figure 1

The architecture of the NFC-enabled device with hybrid model SE and HCE

Full size image

As shown in Fig. 1, the NFC-enabled device is usually composed of various integrated circuits, an NFC interface, and Secure Element (SE). The communications between NFC devices are enabled over the NFC interface. This interface is composed of a contactless front-end, an RF antenna, and an NFC controller that RF antenna is responsible for the transmission and reception of radio signals [33, 34].

The NFC-enabled device incorporates SE to securely store confidential information (such as user account information) and to connect to the NFC controller to perform secure proximity transactions with external NFC devices [33].

However, there may be cloud‐based solutions relying on Host Card Emulation (HCE). HCE removes the need for SE but it results in challenges of security for storing the payment information. Thus, HCE can be combined with other solutions giving a higher level of security (such as SE) [29].

In the proposed protocol using the hybrid model of HCE and SE would provide a highly secure environment. Also, the technology of the proposed scheme based on a combination of the microSD card and NFC antenna that allows the mobile device to communicate with the contactless readers (such as PoS).

Therefore, the SE can be located on the microSD card, while the mobile device takes care of the physical NFC functionality. This solution with the SE stored on the microSD card does not depend on the network operator or device manufacturer, and thus may look attractive for financial institutions as it allows the bank institute that issues the card, to own the SE. Another advantage of the SD‐based SE solution is to facilitate rapid application deployment [29].

In addition to the components listed above, the proposed protocol consists of the main entities of the customer (Alice), the merchant (Bob), the KGC, and the cloud server.

Cloud server can store and process huge data for users. Accordingly, the user of the cloud system does not need to spend expensive costs to increase processing capacity, storage, and battery life on his mobile device. Additionally, mobile cloud computing improves the quality of communications by upgrading bandwidth and reducing data delivery time [7, 35].

The mobile devices such as smartphones and tablets can access cloud services through wireless networks. These devices are connected via base transceiver stations satellites to wireless networks. Base transceiver stations satellites are accountable for controlling the connections and functional interfaces between wireless networks and mobile devices.

Mobile devices transmit the mobile users’ requests and transactions to the base station controllers providing a wide range of wireless network services (such as authentication, authorization, and accounting). The subscribers' requests are then delivered through the Internet to a cloud.

Within the cloud, cloud controllers process the requests and provide mobile users with the corresponding cloud services relying on ubiquitous computing, virtualization, and service-oriented architecture connect to data centers and application servers.

The customer in a private cloud is accountable for guarantee security; but in a public cloud, security accountabilities are shared between the cloud service provider and customers. The customer is accountable for securing applications and data deployed on the cloud platform and cloud service [4].

The interaction of above entities and components is shown in Fig. 2. This interaction is divided into four phases of setup and key generation, time key update, payment transaction, and outsourced verification. In the following, each of these phases is described in detail.

Fig. 2
figure 2

The framework of the proposed protocol

Full size image
Fig. 3
figure 3figure 3figure 3figure 3figure 3

a The declaration part of the ProVerif code. b The KGC process part of the ProVerif code. c The code snippet related to process part of validation algorithm original. d The code snippet related to process part of validation algorithm server-aided. e The main part of the ProVerif code

Full size image

To revoke the user key, the KGC maintains a Malicious-users List (ML). This list contains the pseudo-identity of users whose keys need to be revoked. ML is updated at specific time periods. The cloud server updates the user’s time keys according to the ML received from the KGC in the time key update phase. The cloud server checks ML; if the user’s pseudo-identity is in ML, the cloud server does not generate a new time key for that user. This will automatically revocation the malicious user from the system.

  • Setup and Key Generation Phase: In this phase, KGC selects security parameters as input. Then, it generates the public parameters, the self-private key, the time’s private key, and time-period list \({{T}}{ = (} T_{0}{,\; } T_{1}, \ldots\)) as output. The KGC keeps the self-private key secretly and sends the time’s private key through a secure channel for the cloud server, and publishes the public parameters for all system entities. Additionally, it considers the user’s real identity and the self-private key as input; then it generates a pseudo-identity and partial private key for the user and sends it securely. In this phase, each user chooses a full private key, which is not known by the KGC.

  • Time Key Update Phase: When the cloud server receives an update request from a user, it checks whether the user’s pseudo-identity is found on the ML or not? If the user’s pseudo-identity is in the ML, the cloud server does not accept the update request for that user; otherwise, the cloud server will generate a new time key for the user using the public parameters, time private key, user pseudo-identity, and current time-period.

  • Payment Transaction Phase: In this phase, Alice performs a payment transaction with its full private key, partial private key and time key. Bob also uses the same method to signs a receipt and delivers it to Alice.

  • Outsourced Verification Phase: In this phase, some calculations of signature verification are outsourced to the cloud server. Thus, the computation overhead on the user side significantly decreases.

For a better understanding, the symbols used in the proposed protocol are given in Table 2.

Table 2 Symbols of the proposed protocol
Full size table

3.2 Security requirements

The proposed scheme provides the following security requirements:

  • Unforgeability: No one should impersonate any user and thus create a fake signature.

  • Anonymity: The real identity of users at all stages of the payment transaction must hold hidden.

  • Traceability: Malicious users should be trace.

  • Ability to revoke a key: When a person is abdicated from a responsibility or is identified as a malicious user, that user should be revoke from the system.

  • Non-repudiation: None of the users should be able to deny their sent messages.

4 Proposed scheme

In this section, a new mobile payment protocol is provided using identity-based signature. The proposed protocol based on bilinear pairings and hard computational assumptions is as follows. For convenience, an additive cyclic group \({{G}}_{1}\) and a multiplicative cyclic group \({{G}}_{2}\) of the order \({{q}}\) is considered, where \({{q}}\) is a large prime number. Let \({{P}}\) be a generator of group \({{G}}_{1}\). Then, \(\hat{e}: G_{1} \times G_{1} \to G_{2}\) is an acceptable bilinear mapping if it satisfies the following properties:

Bilinear property For all \(P{,}\, Q\in { \, G}_{1}\) and \(w,\, { z}\in Z_{q}^{*}\) the relation \(\hat{e}\left({{wP}}{,}\,{ zQ}\right){ = }{\hat{{e}}{(}{{P}}{,}\,{ Q}{)}}^{{wz}}\) is established.

Non-degenerate property For all \(P{,}\,{ Q} \in { \, G}_{1}\) the relation \(\hat e(P,\;Q) \ne 1_G{_{{_2}}}\) is established.

Computable property For all \({{P}}{,}\,{ Q} \in { \, {{G}}}_{1}\) exist a polynomial-time algorithm to compute \(\hat{{e}}\left({{P}}{,}\,{ Q}\right) \in { \, {{G}}}_{2}\).

To prove the security of the proposed scheme in the random oracle model, used the following hard assumptions:

Discrete logarithm (DL) problem Given \({(}{{P}}{,}\,{ xP}{)}\) then the \({{x}}\) must be computed. Here, \({{P}} \in {{G}}_{1}\) is a group generator and \({{x}} \in {{Z}}_{{q}}^{*}\) is considered as an unknown parameter.

Computational Diffie–Hellman (CDH) problem Given \({(}{{P}}{,}\,{ xP}{,}\,{ yP}{)}\) then the parameter \({{xyP}}\) must be computed. Here, \({{P}} \in {{G}}_{1}\) is a group generator, and \({{x}}{,}{ y} \in {{Z}}_{{q}}^{*}\) is an unknown parameter.

In hard problems, it is assumed that there is no algorithm with a polynomial-time that can solve them with non-negligible probability.

As noted in Sect. 3.1, the proposed scheme includes the following phases.

4.1 Setup and key generation phase

To setup, KGC selects two cyclic groups \({{G}}_{1}\) and \({{G}}_{2}\) of same prime order \({{q}}\). It considers \({{P}}\) as a group generator of \({{G}}_{1}\) and the mapping \(\hat{e}:G_{1} \times G_{1} \to G_{2}\) as a bilinear pairing. Also, it selects two random elements \({{K}}_{\text{pr}}\text{,}\,{{ t}}_{\text{pr}} \in {{Z}}_{\text{q}}^{*}\) and three one-way hash functions \({{H}}_{1}\text{: }{\left\{\text{0, 1}\right\}}^{*} \rightarrow {{G}}_{1}\), \({{H}}_{2}{:}{ \left\{{0, 1}\right\}}^{*} \times { \left\{\text{0, 1}\right\}}^{*}\rightarrow {{G}}_{1}\), and h \({:}{ \left\{{0, 1}\right\}}^{*} \times {{ G}}_{1} \rightarrow {{Z}}_{{q}}^{*}\). Then, it computes \({{K}}_{\text{pub}}\text{ = }{{K}}_{\text{pr}}{{P}}\), \({{t}}_{\text{pub}}\text{ } = {{ t}}_{\text{pr}}{{P}}\) and \({\beta}{\,=\,}\hat{{e}}{(P,\,P)}\). KGC keeps its private key \({{K}}_{\text{pr}}\) as a secret and sends time private key \({{t}}_{\text{pr}}\) to cloud server via a secure channel. It also publishes the public parameters \({{P}}_{\text{params}}{\,=\,(}{{G}}_{1}{,}\,{{ G}}_{2}{,\,q,\,P,\,}\hat{{e}}{, }\,{{K}}_{\text{pub}}\text{,}\,{\text{ t}}_{\text{pub}}{,\, \beta,\, }{{H}}_{1}{,\, }{{H}}_{2}{,\, h)}\). Finally, the KGC and users for key generation perform the following steps:

Step 1: Alice chooses an \({{ID}}_{{A}} \in {\left\{{0, 1}\right\}}^{*}\) as her real identity and sends \({{ID}}_{{A}}\) to KGC. After that, KGC generates \({{P}}{\text{sd}}_{{A}}\) as Alice’s pseudo-identity and \({{M}}_{{A}}\) as Alice’s partial private key as follows:

Pseudo-identity generation step: In this step, KGC selects \({{w}} \in {{Z}}_{{q}}^{*}\) randomly. Then, it computes \({\text{Psd}}_{{a}}{\,=\,}{{wP}}\) and \({\text{Psd}}_{{a}}^{^{\prime}} = {{ID}}_{{A}} \, \oplus \, {{H}}_{1}{(}{{w}}{{K}}_{\text{pub}}\text{)}.\) Finally, it considers \({{P}}{{sd}}_{{A}}{ = (}{{P}}{{sd}}_{{a}}{, }{\text{Psd}}_{{a}}^{^{\prime}}{)}\) as a pseudo-identity for Alice.

Partial private key generation step: At first, the KGC computes \({{Q}}_{{{P}}{\text{sd}}_{{A}}}{\,=\,}{ \, {{H}}}_{2}{(}{{P}}{\text{sd}}_{{A}}{)}\). Then, it considers \({{M}}_{{A}}{\,=\,}{{K}}_{{pr}}{{{Q}}}_{{{P}}{\text{sd}}_{{A}}}\) as a partial private key for Alice. The KGC sends the pair \(\text{(}{\text{Psd}}_{{A}}{{,}{ M}}_{{A}}{)}\) to Alice through a secure channel.

Step 2: In this step, Alice selects a random element \({{F}}_{{A}} \in {{Z}}_{{q}}^{*}\) as her full private key.

Step 3: Bob does the three steps listed above to compute pseudo-identity \({\text{Psd}}_{{B}}\), partial private key \({{M}}_{{B}}\), and full private key \({{F}}_{{B}}\).

4.2 Time key updating phase

This phase has the following steps:

Step 1: When the cloud server receives Alice’s request for updates, it computes \({{Q}}_{{\text{upd}}_{\text{A}}}\text{ = }{{H}}_{2}{(}{\text{Psd}}_{{A}}{, }{{T}}_{{i}}\text{)}\) and \({{T}}_{{\text{upd}}_{{A}}}= \text{ } {{t}}_{\text{pr}}{{{Q}}}_{{\text{upd}}_{{A}}}\) base on the period \({{T}}_{{i}}\) and then sends \({{T}}_{{\text{upd}}_{{A}}}\) to Alice. Here, \({{P}}{\text{sd}}_{{A}}\) is the pseudo-identity of Alice.

Step 2: Bob gets \({{T}}_{{\text{upd}}_{{B}}}\) like Alice using step 1.

4.3 Payment transaction phase

This phase includes the following steps:

Step 1: First of all, Bob generates a payment request \({\text{Payment = }}{T_{{\text{ID}}}}\left\| {{\text{Amoun}}{{\text{t}}_{\text{T}}}} \right\|{\text{Ps}}{{\text{d}}_{{B}}}\) and sends it to Alice.

Step 2: When Alice receives the payment request, she uses her full private key, partial private key and time key for generating a signature as follows:

$$\alpha {\,=\,}\beta^{{{{F}}_{{{A}}} }} {,}$$
$$v{\,=\,}h{\text{(Payment, }}\alpha {),}$$
$$U{\,=\,}F_{{\text{A}}} P{ + }v{(}M_{{{A}}} { + }T_{{{\text{upd}}_{{{A}}} }} {)}{{.}}$$

Finally, payment signature based on period \({{T}}_{{i}}\) is \(\sigma {\,=\,(}{{U}}{, } \alpha \text{)}\).

Step 3: When Bob receives \(\sigma\), \({\text{Payment}}\), \({{T}}_{{i}}\) and pseudo-identity of Alice, he computes \({{v}}{\,=\,}{{h}}{(}{\text{Payment, }}{\alpha}\text{)}\). Then, checks if \(\hat{{e}}\left({{U}}{, }{{P}}\right)\) \(\,=\,{ } \alpha{\hat{{e}}{(}{{Q}}_{{\text{Psd}}_{{A}}}{, }\;{{K}}_{\text{pub}}\text{)}}^{{v}}{\hat{{e}}{(}{{Q}}_{{\text{upd}}_{{A}}}{,}\;{{ t}}_{\text{pub}}{)}}^{{v}}\) holds. If it was correct, he accepts the output. Otherwise, he stops the process. The correctness of relation above as follows:

$$\begin{aligned} \hat{e}\left( {U{, }P} \right){ } & {\,=\,}\hat{e}\left( {F_{A} P{ + }v{(}M_{A} { + }T_{{{\text{upd}}_{A} }} {), }P} \right) \\& {\,=\,}\hat{e}\left( {F_{A} P, P} \right)\hat{e}{(}M_{A} {, }P{)}^{v} \hat{e}(T_{{{\text{upd}}_{A} }} {, }P{)}^{v} \\ &{\,=\,}\hat{e}{(}P, P{)}^{{F_{A} }} \hat{e}{(}K_{{{\text{pr}}}} Q_{{{\text{Psd}}_{{{A}}} }} {, }P{)}^{v} \hat{e}{(}t_{{{\text{pr}}}} Q_{{{\text{upd}}_{{{A}}} }} {, }P{)}^{v} \\ &{{\,=\,\beta }}^{{F_{A} }} \hat{e}{(}Q_{{{\text{Psd}}_{{{A}}} }} {, }K_{{{\text{pr}}}} P{)}^{v} \hat{e}{(}Q_{{{\text{upd}}_{{{A}}} }} {, }t_{{{\text{pr}}}} P{)}^{v} \\ &{{ = \alpha }}\hat{e}{(}Q_{{{\text{Psd}}_{{{A}}} }} {, }K_{{{\text{pub}}}} {)}^{v} \hat{e}{(}Q_{{{\text{upd}}_{A} }} {, }t_{{{\text{pub}}}} {)}^{v} \\ \end{aligned}$$

Step 4: When Bob verified Alice’s signature and ensured the integrity of payment information, he sets receipt information as \({\text{Receipt}}{\,=\,}{{T}}_{{ID}}{ || }{\text{Amount}}_{{R}}{ || }{\text{Psd}}_{{B}}\) and sings it as follows:

$$\alpha {\,=\,} \beta^{{{{F}}_{{{B}}} }} {,}$$
$$v = h{\text{(Receipt, }}\alpha {),}$$
$$U = F_{B} P + v(M_{B} + T_{{{\text{upd}}_{B} }} ).$$

Step 5: Alice can verify \(\sigma\text{ = (}{{U}}{, } \alpha {)}\) received by Bob as that Step 3 during this phase.

4.4 Outsourced verification phase

In this phase, we use the difficulty of computational assumptions to reduce the computational overhead associated with the signature verification of the cloud server and to prevent the colluding attack (details in Sect. 5.1). For this purpose, Bob and cloud server follow the steps below:

Step 1: When Bob receives \(\sigma\), \({\text{Payment}}\), \({{T}}_{{i}}\) and the pseudo-identity of Alice, he computes \({{v}\,}{\,=\,}\,{{h}}{(}{\text{Payment, }}\alpha {)}\). Then he selects two random elements \({{x}}{, }{{y}} \in {{Z}}_{{q}}^{*}\) and computes \({\sigma}^{^{\prime}}\,{\,=\,}\,{{xU}}{ + }{{yP}}\). Finally, he sends \({\sigma}^{^{\prime}}\), \({{T}}_{{i}}\) and pseudo-identity of Alice to the cloud server.

Step 2: Cloud server computes \({\beta}_{1}\) and \({\beta}_{2}\) as relation follows:

$$\beta_{{1}} \,{ = }\,\hat{e}\left( {\sigma^{\prime}{, }P} \right){,}$$
$$\beta_{{2}} = \hat{e}(Q_{{{\text{Psd}}_{A} }} ,\; K_{{{\text{pub}}}} )\hat{e}(Q_{{{\text{upd}}_{A} }} ,t_{\text{pub}} ).$$

Then, it sends \({\beta}_{1}\) and \({\beta}_{2}\) to Bob.

Step 3: Bob checks the condition \({\beta}_{1}\text{ = }\,{ \alpha}^{\text{x}}{{\beta}_{2}}^{\text{xv}}{\beta}^{\text{ y}}\). If the condition is true, the output is accepted by Bob. Otherwise, the process is stopped. The correctness of this condition as follows:

$$\begin{aligned} \beta_{{1}} { } & {\,=\,}\hat{e}\left( {\sigma^{\prime}{,} P} \right) \\ &{ = }\hat{e}\left( {xU{ + }yP, P} \right) \\ &{ = }\hat{e}\left( {xU, P{)}\hat{e}{(}yP, P} \right) \\& { = }\hat{e}\left( {xF_{A} P{ + }xv{(}M_{A} { + }T_{{{\text{upd}}_{A} }} {), }P} \right)\hat{e}{(}yP, P{)} \\& { = }\hat{e}\left( {xF_{A} P, P} \right)\hat{e}\left( {xM_{A} , P} \right)^{v} \hat{e}{(}xT_{{{\text{upd}}_{A} }} {, }P{)}^{v} \hat{e}\left( {yP, P} \right) \\ &{ = }\hat{e}\left( {xP, P} \right)^{{F_{A} }} \hat{e}{(}xK_{{{\text{pr}}}} Q_{{{\text{Psd}}_{A} }} {, }P{)}^{v} \hat{e}{(}xt_{{{\text{pr}}}} Q_{{{\text{upd}}_{A} }} {, }P{)}^{{\text{v}}} \hat{e}\left( {yP, P} \right) \\& { = }\hat{e}\left( {P, P} \right)^{{xF_{A} }} \hat{e}{(}xQ_{{{\text{Psd}}_{A} }} {, }K_{{{\text{pr}}}} P{)}^{v} \hat{e}{(}xQ_{{{\text{upd}}_{A} }} {, }t_{{{\text{pr}}}} P{)}^{v} \hat{e}\left( {yP, P} \right) \\ &{ = (}\beta^{{F_{A} }} {)}^{x} \hat{e}{(}xQ_{{Psd_{A} }} {, }K_{{{\text{pub}}}} {)}^{v} \hat{e}{(}xQ_{{{\text{upd}}_{{\text{A}}} }} {, }t_{{{\text{pub}}}} {)}^{v} \hat{e}\left( {yP, P} \right)& \\& { = }\alpha^{x} \left( {\hat{e}{(}Q_{{{\text{Psd}}_{A} }} {, }K_{{{\text{pub}}}} {)}\hat{e}{(}Q_{{{\text{upd}}_{A} }} {, }t_{{{\text{pub}}}} {)}} \right)^{xv} \hat{e}{(}P, P{)}^{{{ }y}} \\ &{ = }\alpha^{x} \beta_{{2}}^{xv} \beta^{ y} . \\ \end{aligned}$$

Step 4: By following the steps above in this phase, Alice can check the validity of Bob’s signature.

5 The proposed scheme analysis

In this section, the proposed scheme is evaluated by security and efficiency metrics. As discussed in Sect. 2, systems that are based on identity-based signatures prevent issues related to digital certificates and public key infrastructure. For this reason, only mobile payment systems based on IBS [24, 27] are used to perform comparisons.

5.1 Security analysis

Now, the security of the proposed scheme is analyzed as follows:

  • Unforgeability: In the proposed scheme, only legal users can generate make signatures of the payment and receipt requests; because used the unforgeable signature scheme [36] for this work.

  • Anonymity: The identity of users is kept secret at all stages. The real identity of each user is converted into a pseudo-identity pair \({(}{{P}}{\text{sd}}_{{i}}, {\text{ Psd}}_{{i}}^{^{\prime}}{)}\) for the unknown \({{w}} \in {{Z}}_{{q}}^{*}\). This pseudo-identity pair is an ElGamal-type ciphertext in the ECC that is resistance against chosen-plaintext attacks. Therefore, without the KGC’s private key \({{K}}_{\text{pr}}\), there is no way to extract the real identity of users from their pseudo-identity pair.

  • Tractability: KGC can obtain the pseudo-identity pair through payment signature or the signature of receipt. Then, it can use the self-private key to extract the user’s real identity.

  • Key revocation property: When the user is denied responsibility or the person is identified as a malicious user, KGC puts the pseudo-identity of the user in an ML and sends the ML to the cloud server. Thus, when the user sends an update request to the cloud server, the cloud server by checking the ML found that the user’s pseudo-identity exist in the list; therefore, it does not accept the time key update request of the user.

  • Non-repudiation: Bob and Alice cannot deny receipt signature and payment signature, respectively. Otherwise, KGC can be tracing and revocation them.

  • Secure against colluding attack: If Alice colludes with the cloud server in the outsourced verification phase, Bob not accepted Alice's invalid signature; because the discrete logarithm problem is used in the structure of \({\sigma}^{^{\prime}}\text{.}\) Therefore, the cloud server cannot obtain \({{x}}\) and \({{y}}\) through the relation between \({\sigma}^{^{\prime}}\) and \({{U}}\). As a result, the proposed scheme remains secure against colluding attack.

  • Solving the key escrow problem: In the proposed scheme, each user chooses a fully private key, which even the KGC is unaware of it. Then, users use their fully private keys to do their transactions. In this way, KGC’s potential misconduct is prevented.

5.2 Formal security validation Using ProVerif

Here, the security of the proposed protocol is evaluated using ProVerif [37, 38]. ProVerif is an automated security tool for validating security protocols against known active and passive attacks. This tool supports a wide range of cryptographic primitives and is defined by predefined rules. Also, it can check every protocol for an unbounded message space and an unbounded number of sessions.

Implementations of the proposed scheme using ProVerif in both modes the original validation algorithm and the validation algorithm server-aided are shown in Fig. 3a–e. These implementations include three parts of the declaration, the process, and the main part. The declaration part, the KGC process, and the main part are the same in both implementations. In the declaration part, channels, constants, and variables besides cryptographic functions are delineated as constructors and equations. In the process part, the definition of processes and sub-processes are elaborated. In the main part, the initiation and termination of participating users are specified, and execution processes are kept parallel. Finally, three queries are executed in order to rectify the correctness and security of the proposed scheme.

The results of all queries (in both the original validation algorithm and the validation algorithm server-aided) are presented in Fig. 4. In these results, the correctness of the proposed scheme is substantiated, since the first two questions are executed successfully. Also, its security is confirmed due to unsuccessful query attack on session key Kij.

Fig. 4
figure 4

Results from the implementations of the proposed scheme using ProVerif

Full size image
Fig. 5
figure 5

Compare of relative times of cryptographic operations

Full size image
Fig. 6
figure 6

Performance comparisons based on signature validation algorithms

Full size image

5.3 Security comparison

Table 3 shows a comparison between the proposed scheme and other similar schemes from the security point of view. Protocols that are resistant to attacks and provide malicious revocation users from the system are more secure protocols.

Table 3 Security comparison
Full size table

5.4 Performance evaluation

In this section, the proposed protocol is compared with the previous similar schemes from the point of view of performance. Performance evaluation is performed based on the experimental results of the Study [36]; In this study for that purpose, was used the MIRACL library [39] that the system specifications for implementation are shown in Table 4.

Here, performance evaluation is done precisely as same as the study [27]. Also, for convenience, the symbols in Table 5 are used to perform performance comparisons. The relative times for cryptographic operations is given in Fig. 5. Table 6 summarizes the number of cryptographic operations related to signature verification in the proposed scheme and other similar schemes. Figure 6, shows the total running time of the proposed system and other similar protocols in two modes of the original validation algorithm and server-aided validation algorithm.

According to Fig. 5, the executing time of the bilinear pairing (5.275 ms) and scalar multiplication (1.970 ms) is much higher than the other operations. For this reason, with the fewer number of bilinear pairings and scalar multiplication operations, the efficiency of the protocol increases.

According to Table 6, the proposed scheme compared to the protocol [24] reduces the number of bilinear pairings in the signature verification sever-aided (from 1 to 0). Also, the proposed scheme compared to the protocol [27] reduces the number of scalar multiplication operations in the signature verification sever-aided (from 4 to 3). Therefore as shown in Fig. 6, the proposed scheme leads to an increase in the speed (efficiency) for signature validation server-aided to 6.918 ms.

Table 4 System specifications for implementation
Full size table
Table 5 Symbols for performance comparisons
Full size table
Table 6 The number of cryptographic operations for signature verification
Full size table

6 Conclusion

The nature of the open media in wireless communications and the limited resources of mobile devices has led to great security challenges in mobile payment systems. In this paper, we proposed a new mobile payment system through an identity-based unforgeable signature. So that avoids additional costs due to the lack of digital certificates and provides non-repudiation and tracing capabilities. Also, this system provides an anonymity feature for users using the pseudo-identity method and provides key revocation uses the malicious user lists that contains the pseudo-identity of malicious users. To solve the problem of key escrow, we used the full private key of users (which was not known by the key generation center) for doing transactions in the scheme. In this plan, to reduce computational overhead, we outsourced some calculations to the cloud server, and also we used algorithms with less computational overhead. Thus, the proposed scheme has increased the speed of the signature verification phase compared to previous schemes.

The security analysis showed that the proposed protocol provides more security properties than similar schemes. In this regard, we implemented the model using the ProVerif automatic tool, and the results showed that the proposed scheme is secure against active and passive attacks. Besides, the proposed design uses cloud-based logic technology to communicate between mobile devices and fast deployment of the protocol.