Lightweight and Secure IoT-Based Payment Protocols from an Identity-Based Signature Scheme

Abstract

After the great success of mobile wallets, the Internet of Things (IoT) leaves the door wide open for consumers to use their connected devices to access their bank accounts and perform routine banking activities from anywhere, anytime, and with any device. However, consumers need to feel safe when interacting with IoT-based payment systems, and their personal information should be protected as much as possible. Unlike what is usually found in the literature, in this paper, we introduce two lightweight and secure IoT-based payment protocols based on an identity-based signature scheme. We adopt a server-aided verification technique to construct the first scheme. This technique allows to outsource the heavy computation overhead on the sensor node to a cloud server while maintaining the user’s privacy. The second scheme is built upon a pairing-free ECC-based security protocol to avoid the heavy computational complexity of bilinear pairing operations. The security reduction results of both schemes are held in the Random Oracle Model (ROM) under the discrete logarithm and computational Diffie–Hellman assumptions. Finally, we experimentally compare the proposed schemes against each other and against the original scheme on the most commonly used IoT devices: a smartphone, a smartwatch, and the embedded device Raspberry Pi. Compared with existing schemes, our proposed schemes achieve significant efficiency in terms of communication, computational and storage overheads.

1. Introduction

Financial services and the payment industry are constantly evolving to meet customer requirements and to create a competitive advantage by providing better banking and financial services, improving operational efficiency and reducing costs. After plastic cards were successfully replaced by the mobile wallet (m-Wallet) [1], the Internet of Things (IoT) leaves the door wide open for consumers to use their connected devices to access their bank accounts and perform routine banking activities from anywhere, anytime, and with any device. For instance, a connected watch can be used by a customer to conduct payment at a store, while a driver can pay for parking and fuel via a connected car. Furthermore, more milk can be bought automatically through a connected refrigerator. All these payment scenarios are categorized in the so-called IoT-based payment systems. The trend toward IoT-based payment systems started in the last few years and accelerated in 2018 [2].

As one of the effective methods of IoT-based payment systems, an in-vehicle payment solution has recently been launched by two leading credit card companies: Visa and MasterCard. In this solution, the driver is alerted when he/she is near a smart parking meter or fuel pump. At payment time, the amount of the purchased service is displayed in the dashboard. Afterwards, the entire payment process is simply completed with just a touch of a button. In addition to in-vehicle payments, wearable payment systems [3,4] have innovatively integrated payment methods into wearable devices such as smartwatches, jewelry, wristbands, fitness bands, and other adaptable wearables.

An IoT-based payment system offers substantial efficiency benefits for both buyers and sellers, and both individuals and businesses. The consumers receive shorter transaction time with high comfort and fast real-time response. Furthermore, their financial habits will improve as the IoT-based payment system supports them to spend their money wisely. For example, to prevent oversupply, reordering only occurs when the product is running low. On the other hand, the traders can gain more customers by ensuring IoT-friendliness, automating their logistics processes using smart shelves, and optimizing checkout and customer service by accepting IoT wallets.

Along with the many benefits of the IoT-based payment system, the associated risks and threats [5,6] cannot be omitted. With so many payment data shared across many IoT devices and things, it is inevitable that hackers and malicious users will try to obtain access to these most valuable and vulnerable data.

1.1. Motivations

Most breaches have financial motivations. These breaches aim to obtain information such as financial account information, users’ credentials, or online banking details. Once the users’ credentials are stolen, hackers misuse them to gain illegal access to the victim’s account, defraud institutions, or commit other financial crimes.

To ensure that clients derive the maximum benefits and enjoy the appealing features of IoT-based payment systems, credit card companies and their partners should consider the following challenges. First, it is essential to guarantee that nobody is allowed to impersonate any customer or create a fake payment request to steal funds. Otherwise, forgery and fraud will abort the invention of IoT-based payments in its initial stages. Second, anonymity and privacy have a significant influence on a user’s attitude toward IoT-based payment systems. To increase the usage, acceptance, and adoption of IoT-based payment systems, the personal information of consumers should be protected as much as possible. Furthermore, consumers need to feel safe when interacting with IoT-based payment systems. Third, the IoT embedded devices are extremely limited in resources such as storage capacity, processing capabilities, communication bandwidth, and battery lifetime. Therefore, traditional encryption and authentication methods cannot be directly applied on sensor nodes in the IoT-based payment scenarios. This issue could be resolved by outsourcing the heavy computation overhead on sensor nodes to cloud servers while maintaining the user’s privacy. Another solution lies in adopting pairing-free ECC-based security protocols. In this paper, both solutions are adopted to introduce two lightweight and agile IoT-based payment protocols.

A digital signature [7] is a fundamental cryptographic primitive that offers nonrepudiation, unforgeability, and authenticity of electronic payment systems. However, the traditional public key-based digital signature suffers from the complex certificate management. Fortunately, due to its certificate-free property, the identity-based signature (IBS) [8,9] has been introduced to simplify the complexity and reduce the heavy cost of certificate management in traditional public key-based digital signatures. Therefore, it is interesting and challenging to design a lightweight and secure IoT-based payment method based on the idea of an identity-based signature.

1.2. Contribution

Motivated by the limited resources of IoT devices, we introduce two lightweight and secure IoT-based payment protocols based on an identity-based signature scheme, where each run a different lightweight computation and communication costs to suit the varying capabilities of IoT devices with limited resources. Then, we experimentally compare the proposed schemes against each other and against existing schemes on the most commonly used IoT devices: a smartphone, a smartwatch, and the embedded device Raspberry Pi. To summarize, the major contributions of this article are twofold:

• We introduce a lightweight and secure IoT-based payment scheme based on an identity-based signature scheme. To preserve the limited resources of IoT embedded devices and to meet the IoT-based payment system’s goal of conserving bandwidth consumption, energy, and processing power, we adopt a server-aided verification technique to reduce the heavy verification overhead. We further provide a security analysis of our proposed protocol to examine its correctness and soundness.
• We propose an alternative solution of using a server-aided verification technique in the IoT-based payment scheme by adopting a pairing-free ECC-based security protocol. We then experimentally compare our pairing-free IoT-based payment scheme against original and server-aided verification protocols. The security reduction results of the second proposed scheme are held in the Random Oracle Model (ROM) under the discrete logarithm assumption.

The rest of this paper is organized as follows. In Section 2, we discuss works related to our study. A high-level description of the proposed protocols and mathematical backgrounds are given in Section 3. In Section 4, the details of the proposed IoT-based payment protocols are presented. Through Section 5 and Section 6, a security analysis and performance evaluation are analyzed, followed by the conclusion and future work in Section 7.

2. Related Work

Throughout time, cashless-based payment systems have evolved several times from smart cards to smart phones and Internet banking. The current trends for cashless-based payment systems include the debit and credit cards, Samsung Pay, Google Pay, Apple Pay, Wechat Pay, AliPay, and many more mobile banking applications. This paper is primarily related to electronic payment systems, mobile wallets, micropayments, and contactless payment systems.

2.1. Electronic Payment Systems

The financial technology (FinTech) sector [10] is an industry that leverages new technologies to provide secure, instant, and efficient financial services. Its services (e.g., mobile banking apps) have been widely adopted by financial institutions. However, as revealed by the recent study [11], the FinTech financial services are not as secure as we expected. The study discovered thousands of vulnerabilities in 693 banking apps across over 80 countries, many of which could cause serious consequences, such as sensitive information leakage (e.g., PIN code, user name, or users’ credentials). Once the users’ credentials are stolen, hackers misuse them to gain illegal access to the victim’s account, defraud institutions, and other such financial and identity crimes.

In academia, many electronic payment systems have been proposed [12,13,14,15,16]. These systems aim to deliver payments from consumers to merchants in the most effective, efficient, and error-free way, particularly in combination with attractive security properties. Unfortunately, each system is limited in some aspect.

2.2. Contactless Payment

Google Wallet launched the first (contactless) payment system in 2011. Subsequently, it was followed by both Apple and Samsung Pay in 2014 and 2015, respectively. Additionally in 2015, Android Pay was announced as a new contactless system. Traditional contactless payments use cards. Now, the majority of them follow Europay, MasterCard, and Visa (EMV) contactless specifications [17]. In a mobile contactless payment system, the user is allowed to use the virtual debit and credit card information to securely pay for the purchases in store with those cards by waving the smart phone in front of the near-field communication point-of-sale (NFC-POS).

The contactless payment can be classified according to the amount of money transferred into two main types: micro and macro [18]. In a micro payment, the user makes a small contactless transaction with touch-and-go practice, while in the macro payment, the user conducts a big amount transaction with touch-and-confirm practice.

Despite the great convenience brought by mobile contactless payment systems, fraud remains a significant consumer concern. Recent research [19] showed that 38% of users have a strong feeling that contactless payments are insecure, and around half (51%) are very or extremely concerned about fraud. As a result, 30% of all users with contactless cards still do not use them.

2.3. Mobile Wallet

A mobile wallet (m-Wallet) is a virtual wallet that keeps payment card information on a mobile device. Mobile wallets are a convenient way for a consumer to conduct in-store, in-app, or online payments. In 2017, Qin et al. [1] introduced a secure and privacy-preserving mobile wallet by incorporating the certificateless signature and pseudo identity technique. Their approach significantly reduces the computation overhead in a resource-limited mobile device by offloading the heavy computation overhead on the user side to the untrusted cloud server. However, their payment protocol is insecure against a collusion attack between the customer, Alice, and the cloud server at the server-aided verification phase, as proved in [20]. Because the cloud server is untrusted, there is no way to verify whether the returned information is valid or not. By considering the benefits of certificate-free property, Yeh and Chen et al. [21,22] proposed IoT-based payment protocols based on certificateless cryptography primitives. However, despite the security proofs, Zirui et al. [23] proved that the Yeh [21] protocol is insecure against public key replacement attack, while Chen et al. [22] suffers from perfect forward secrecy and replay attacks, as shown in [24]. The work by Şengel et al. [25] proposed a new mobile payment cryptographic solution model, and this solution stores clients’ credentials in the memory of the device; however, keeping users’ credentials (private keys and PIN) in the memory of a handset is very risky as these credentials can be easily compromised. A fully offline transaction e-commerce system model based on mobile payment, which includes the offline POS terminal, mobile device, and payment center, was proposed by Li et al. [26], but it has limitations in day-to-day customer–merchant transactions, as it requires an additional POS terminal.

Despite the security requirements of IoT-based payment seeming similar to those identified in the literature, the limited resources of IoT devices such as storage capacity, processing capabilities, communication bandwidth, and battery lifetime make the problem very novel and challenging. Furthermore, to the best of our knowledge, none of the state-of-the-art systems are designed to operate over IoT devices with limited resources.

3. Preliminaries

In this section, we first describe the system model. Then, the basic definitions and assumptions that are needed in the remainder of the paper are presented.

3.1. System Model

The scope of this section is to provide an overview of our proposed model. Our system model consists of the following participants:

• Buyer: Alice. A consumer who wants to purchase products or services from the seller.
• Seller: Bob. A trader who offers goods or services for sale either online or in store.
• Payment Service Provider ($\mathcal{PSP}$): Responsible for ensuring payment security and privacy. The $\mathcal{PSP}$ performs cryptographic initialization and user management.
• Cloud server provider ($\mathcal{CSP}$): This entity performs server-aided verification to reduce the heavy computational overhead on the sensor node.

The interaction scenario between the above participants is expressed graphically in Figure 1. Alice and Bob communicate with each other and with the other entities using short-range wireless communication protocol standards, such as NFC (IEEE 802.11), Bluetooth (IEEE 802.15.1), WiFi, or Zig-Bee (IEEE802.15.4), whereas the $\mathcal{PSP}$ and $\mathcal{CSP}$ are located and operated in the fixed network. The players take part in the following three phases of an IoT-based payment system: the initialization phase, payment phase, and verification phase. In the initialization phase, the $\mathcal{PSP}$ initializes and assigns the system parameters for each user. Then, it anonymously generates the user’s pseudo identity using a tamper-proof device. In IoT-based payment systems, the IoT smart device alerts the user to purchase the necessary goods or services. For example, in our model, a smart refrigerator reminds Alice to buy more milk, whereas her smart vehicle notifies her when she is near a smart parking meter or fuel pump. In the payment phase, Alice uses her connected device to conduct the payment. There are three payment options that correspond to IoT smart devices: in-store, in-app or online. For an in-store payment, Alice tries to conduct a payment transaction using her wearable or handheld device and Bob’s near-field communication point-of-sale (NFC-POS). To perform this, Bob initiates a payment request on his NFC-POS. Afterward, Alice waves her wearable device near the NFC-POS, then she confirms the payment with her digital signature. For an in-app payment, Alice uses application program interfaces (APIs) to handle payments and transactions with just a touch of a button. For online payments, Alice performs the payment transaction remotely over the Internet, using a wireless connection. Once Alice has completed the payment process, Bob uses Alice’s public key to check the validity of Alice’s signature and to ensure the payment integrity. Finally, after Alice’s payment has passed the verification, Bob uses his private key to sign a receipt for the amount that he received.

3.2. Elliptic Curves Cryptography (ECC)

Miller and Koblitz [27,28] individually suggested the use of elliptic curves in cryptography in the middle of the 1980s. Several years later, elliptic curves cryptography (ECC) has attracted much attention from scientists, engineers, and researchers worldwide. Today, ECC plays an important role in public key cryptography. Compared with RSA, ECC-based cryptosystems provide a high security level with a small key size and more efficient implementations [29]. Let $q>3$ be a prime number and $E_q(a,b)$ be a nonsingular elliptic curve over $F_q$, which can be defined as the Weierstrass form.

$$\begin{array}{c}\hfill y^2=x^3+ax+b,\end{array}$$

(1)

where $a,b,x,y\in F_q$ with the discriminant $▵=(4a^2+27b^2)modq\ne 0$. A point $P(x,y)$ is an elliptic curve point if it satisfies Equation (1), and the point $Q(x,-y)$ is called the negative of P, i.e., $Q=-P$. The points $E_q(a,b)$ together with a point $\mathcal{O}$ (called point at infinity) form an additive cyclic group $\mathbb{G}$, that is, $\mathbb{G}=\{(x,y):a,b,x,y\in F_q$ and $(x,y)\in E_q(a,b)\}\bigcup \left\{\mathcal{O}\right\}$ of prime order q. Scalar multiplication over $E|F_q$ can be computed as follows:

$$\begin{array}{c}\hfill tP=P+P+...+P_{\left(ttimes\right)}\end{array}$$

(2)

3.3. Bilinear Pairing

Let $\mathbb{G}$ and ${\mathbb{G}}_T$ be two cyclic groups of the same large prime q. Let $g_1$ be generators of $\mathbb{G}$. Assume that the discrete logarithm in $\mathbb{G}$ and ${\mathbb{G}}_T$ are hard. Let $\widehat{e}:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$ be an admissible pairing that satisfies the following properties:

• Bilinear: Given $g_1,g_2,g_3\in \mathbb{G}$, we have
  $\widehat{e}(g_1,g_2+g_3)=\widehat{e}(g_1,g_2)·\widehat{e}(g_1,g_3)$.
  For any $a,b,\in {\mathbb{Z}}_p^{*}$, we have
  $\widehat{e}(a{g}_1,b{g}_2)=\widehat{e}{(g_1,g_2)}^{ab}=\widehat{e}{(g_1,b{g}_2)}^a=\widehat{e}{(a{g}_1,g_2)}^b=\widehat{e}(ab{g}_1,g_2)=\widehat{e}(g_1,ab{g}_2)$.
• Non-degenerate: There exists $g_1,g_2\in \mathbb{G}$ such that $\widehat{e}(g_1,g_2)\ne 1$. This means that if $g_1$ and $g_2$ are two generators of $\mathbb{G}$, then $\widehat{e}(g_1,g_2)$ is a generator of ${\mathbb{G}}_T$.
• Computability: There is an efficient algorithm to compute $\widehat{e}(g_1,g_2)$ for all $g_1,g_2\in \mathbb{G}$.

3.4. Computational Hardness Assumption

Our scheme is based on the hardness assumptions as follows:

• Discrete logarithm (DL) problem: Given a generator $g_1$ of a cyclic group ${\mathbb{G}}^{*}$ with order q, then compute $g_2=g_1^a$ for a random $a\in {\mathbb{Z}}_q^{*}$.
• Computational Diffie–Hellman (CDH) problem: Given (g, $g^a$, $g^b$) then compute $g^{ab}$, where $g\in \mathbb{G}$ is the generator and $a,b\in {\mathbb{Z}}_q^{*}$ is unknown.

3.5. Design Goals

To maintain the IoT-based payment security, our protocols should be able to satisfy the following requirements:

• Unforgeability: Only authorized users are allowed to make transactions. In other words, nobody can impersonate Alice or Bob to create a fake payment request or a fake or illegal receipt. Let $\mathcal{A}$ be a CDH attacker which attacks the IoT-based payment protocol and $\mathcal{F}$ be a forger who attacks the identity-based signature scheme (IBS). The forger $\mathcal{F}$ performs the IoT-based payment protocol instead of the $\mathcal{PSP}$ without knowing the $\mathcal{PSP}$’s secret master key. The attacker $\mathcal{A}$ plays the following game with $\mathcal{F}$.

  (a)

  Setup: The $\mathcal{A}$ runs the setup algorithm to generate the system’s parameters and sends them to the forger $\mathcal{F}$.

  (b)

  Queries: The forger $\mathcal{F}$ performs a series of queries to the following oracles:

  • Extract query: Key extraction oracle: returns private keys for arbitrary identities.
  • Sign query: Signature oracle: produces signatures on arbitrary messages using the private key corresponding to arbitrary identities.

  (c)

  Forgery: $\mathcal{F}$ produces a triple ($I{D}^{*}$, $M^{*}$, ${\sigma }^{*}$) made of an identity $I{D}^{*}$, whose private key was never extracted, and a message–signature pair ($M^{*}$, ${\sigma }^{*}$) such that ($M^{*}$, $I{D}^{*}$) was not submitted to the signature oracle. She wins if the verification algorithm accepts the triple ($I{D}^{*}$, $M^{*}$, ${\sigma }^{*}$).

• Anonymity: The real identity of Alice is only known to the $\mathcal{PSP}$ and Alice herself. Alice should be able to deal with Bob without disclosing her real identity. The same holds true when Bob signs a receipt.
• Traceability and Revocation: The real identity of the malicious user must be traceable and revoked, but only by the $\mathcal{PSP}$. Malicious users must be prevented from accessing the tamper-proof device. Malicious users must be revoked and kicked out of the payment protocol, but only by the $\mathcal{PSP}$.
• Unlinkability: In our protocols, any user can conduct multiple payment transactions without others being able to link these transactions to a particular user. The proposed IoT-based payment protocols cannot be hacked by an attacker with any linkable information.
• Nonrepudiation: Alice should not be able to deny the confirmed transaction. Bob also cannot deny that he received the amount paid by Alice.
• Resistance to Replay Attack: An adversary cannot reuse the previously exchanged valid information to obtain the corresponding service.
• Resistance to Impersonation Attack: An adversary cannot impersonate Alice or Bob to create a fake payment request or a fake or illegal receipt.
• Mutual Authentication: Alice and Bob should authenticate each other before actual communication occurs to avoid the potential malicious attacks.

In addition to the above security requirements, low energy and bandwidth consumption with other low-cost design capabilities are extremely desired properties in IoT-based payment systems.

4. Proposed Schemes

In this section, we concretely construct two lightweight IoT-based payment schemes. Both schemes are built upon an identity-based signature scheme. The first protocol is constructed based on Tzeng et al.’s scheme [30], and the second protocol relies on the Hu et al. scheme [31]. We employ server-aided verification protocols [32] to introduce the first scheme, while the second scheme is constructed based on a pairing-free approach. For convenience, the notations of the proposed scheme are defined in

Table 1. Notations.

Acronym	Description
$\mathcal{PSP}$	Payment service provider
$\mathcal{CSP}$	Untrusted cloud server provider
$I{D}_A$	Alice’s real identity
$P{W}_A$	Alice’s password
$PI{D}_A$	Alice’s anonymous identity
$I{D}_B$	Bob’s real identity
$P{W}_B$	Bob’s password
$PI{D}_B$	Bob’s anonymous identity
$H_1,H_2$	Two hash functions
$\sigma$	A signature on message M
$\mathsf{PP}$	Public parameters
$P_{pub}$	The $\mathcal{PSP}$’s public master key
T	The current timestamp
$\widehat{e}$	A bilinear pairing
⊕	An exclusive-OR (XOR)

.

4.1. Scheme I: IoT-Based Payment Scheme with Server-Aided Verification

An IoT-based payment scheme with a server-aided verification consists of the following phases:

• Initialization Phase
  In this phase, the $\mathcal{PSP}$ initializes and assigns the system parameters for each user. These include two groups, $\mathbb{G}$ and ${\mathbb{G}}_T$, of prime order q and a bilinear pairing $\widehat{e}:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$. Let $g_1$ and $g_2$ denote two generators in $\mathbb{G}$. It next randomly selects its secret master key $a{\in }_R{\mathbb{Z}}_q^{*}$ and computes its public master key $P_{pub}=g_1^a$. It also selects two hash functions, $H_1$ and $H_2$. For the first registration of Alice and Bob, $\mathcal{PSP}$ assigns real identities $I{D}_A,I{D}_B\in \mathbb{G}$ and passwords $P{W}_A$ and $P{W}_B$ for Alice and Bob, respectively. $\mathcal{PSP}$ then stores $(a,I{D}_A,I{D}_B,P{W}_A,P{W}_B)$ into the tamper-proof device. Finally, $\mathcal{PSP}$ announces the public parameters: $\mathsf{PP}=(\mathbb{G},{\mathbb{G}}_T,q,\widehat{e},g_1,g_2,P_{pub},{\lambda }_1,H_1,H_2)$, where ${\lambda }_1=\widehat{e}(g_1,g_1)$.
• Payment Phase
  According to IoT device capabilities, there are three payment options: in-store, in-app, or online. For in-store payments, Alice tries to conduct a payment transaction using her wearable or handheld device and Bob’s near-field communication point-of-sale (NFC-POS), whereas APIs are used to handle payments and transactions with just a touch of a button in the in-app payment scenario. For online payments, Alice conducts a payment transaction remotely over the Internet, using a 4G/5G or WiFi wireless connection. The following steps illustrate how this can be performed:
  • Step 1: Bob initiates a payment request on his NFC-POS, app, or website by encoding the payment amount information into a message M.
  • Step 2: Upon receiving the payment request, Alice logs in into the tamper-proof device using her real identity $I{D}_A$ and password $P{W}_A$. If an incorrect $I{D}_A$ or $P{W}_A$ is entered, the tamper-proof device terminates the current process and refuses to perform further modules. On the other hand, if Alice passes the authentication module, then her real identity $I{D}_A$ is transferred to the next module, the pseudo identity generation module. Figure 2 shows the procedures and modules of the tamper-proof device.
  • Step 3: The pseudo identity generation module composes Alice’s pseudo identity $PI{D}_A$ into $PI{D}_{A,1}$ and $PI{D}_{A,2}$. It then picks $x\in {\mathbb{Z}}_q^{*}$ and computes the pseudo identity $PI{D}_A$ as follows:

    $$\begin{array}{c}\hfill PI{D}_{A,1}=g_1^x\end{array}$$

    $$\begin{array}{c}\hfill PI{D}_{A,2}=I{D}_A\oplus H_1\left(P_{pub}^x\right)\end{array}$$
    Finally, the pseudo identity generation module sets Alice’s pseudo identity as $PI{D}_A=(PI{D}_{A,1},PI{D}_{A,2})$.
  • Step 4: Alice inputs the message M into the tamper-proof device. The tamper-proof device uses Alice’s pseudo identity $PI{D}_A$, x and a current timestamp T to generate the signature $\sigma$ of M as follows:

    -

    Compute $V=H_2\left(M\right||PI{D}_A\left|\right|T)$.

    -

    Compute $U=V·g_2^{x+a}$.

    Afterward, Alice obtains the final $\{M,PI{D}_A,\sigma =(U,V),T\}$ and sends it to Bob.
• Verification Phase
  Upon receiving the final message from Alice, Bob checks the validity of the signature to ensure the integrity of the payment information. To preserve the limited resources and help to meet the IoT-based payment system’s goal of conserving bandwidth consumption, energy, and processing power, we adopt a server-aided verification technique to minimize the number of pairing operations in the original verification process. The details of the original and server-aided verifications are described as follows.

  (a)

  Original verification: Given the final message $\{M,PI{D}_A,\sigma =(U,V),T\}$ sent by Alice, Bob uses the public parameters $\mathsf{PP}=(\mathbb{G},{\mathbb{G}}_T,q,\widehat{e},g_1,g_2,P_{pub},{\lambda }_1,H_1,H_2)$ published by the $\mathcal{PSP}$ to check the validity of the signature as follows.

  • Step 1: To resist the replaying attack, Bob checks the freshness of the final message. Assume that the receiving time is $T_B$. Bob checks whether $\Delta T\ge T_B-T$. If it does, then Bob continues; otherwise, he rejects it.
  • Step 2: Bob verifies the signature by checking whether $\widehat{e}(U,g_1)\stackrel{?}{=}\widehat{e}(PI{D}_{A,1}·V·P_{pub},g_2)$ holds or not. If it does, output is valid, otherwise output is ⊥.

  (b)

  Server-aided verification: As indicated in Step 2 during the original verification, two pairing operations are required to verify the signature. However, a bilinear pairing operation is computationally more expensive than other operations over elliptic curve groups. To minimize the number of pairing operations, Bob delegates an untrusted cloud server provider $\mathcal{CSP}$ to perform server-aided verification. The following steps and Figure 3 illustrate how Bob and $\mathcal{CSP}$ interact with each other.

  • Step 1: To check the freshness of the final message, Step 1 of the original verification is repeated here.
  • Step 2: Given public parameters $\mathsf{PP}=(\mathbb{G},{\mathbb{G}}_T,q,\widehat{e},g_1,g_2,P_{pub},{\lambda }_1,H_1,H_2)$ and the final message $\{M,PI{D}_A,\sigma =(U,V),T\}$, Bob randomly chooses $r,t\in {\mathbb{Z}}_q^{*}$ and computes $U^{\prime }=U·g_1^r$ and $V^{\prime }=V·g_2^t$. He then sets ${\sigma }^{\prime }=(U^{\prime },V^{\prime })$. Afterward, he sends the message and blind signature $\{PI{D}_{A,1},{\sigma }^{\prime },T\}$ to the $\mathcal{CSP}$.
  • Step 3: Upon the $\mathcal{CSP}$ receiving $\{PI{D}_{A,1},{\sigma }^{\prime },T\}$ from Bob, it computes ${\lambda }_2=\widehat{e}(U^{\prime },g_1)$ and ${\lambda }_3=\widehat{e}(PI{D}_{A,1}·P_{pub},V^{\prime })$. It then sends ${\lambda }_2,{\lambda }_3$ to Bob.
  • Step 4: Bob checks if ${\lambda }_2\stackrel{?}{=}{\lambda }_3^{-t}·{\lambda }_1^r$. If it does, output is valid, otherwise output is ⊥.

4.2. Scheme II: Pairing-Free IoT-Based Payment Scheme

In this section, our second pairing-free IoT-based payment scheme is introduced. This scheme is constructed based on Hu et al.’s scheme. Our second scheme consists of three phases, as in Scheme I: the initialization phase, the payment phase, and the verification phase.

• Initialization phase
  Initially, the $\mathcal{PSP}$ inputs the security parameters k and determines the tuple
  {$F_q,E|F_q,\mathbb{G},P$} as defined in Section 3.2. Then, it picks the secret master key $a\in {\mathbb{Z}}_q^{*}$ and computes its public master key $P_{pub}=P^a$. Next, $\mathcal{PSP}$ chooses two hash functions, $H_1$ and $H_2$. Finally, the $\mathcal{PSP}$ publishes the system parameters: $\mathsf{PP}=(F_q,E|F_q,\mathbb{G},P,P_{pub},H_1,H_2)$.
• Payment Phase
  Steps 1 and 2 are the same as steps 1 and 2 of Scheme I during the same phase. The main differences are in step 3 and step 4.
  • Step 3: The pseudo identity generation module composes Alice’s pseudo identity $PI{D}_A$ into $PI{D}_{A,1}$ and $PI{D}_{A,2}$. It then picks $x\in {\mathbb{Z}}_q^{*}$ and computes pseudo identity $PI{D}_A$ as follows:

    $$\begin{array}{c}\hfill PI{D}_{A,1}=P^x\end{array}$$

    $$\begin{array}{c}\hfill PI{D}_{A,2}=I{D}_A\oplus H_1\left(P_{pub}^x\right)\end{array}$$
    Finally, the pseudo identity generation module sets Alice’s pseudo identity as $PI{D}_A=(PI{D}_{A,1},PI{D}_{A,2})$.
  • Step 4: Alice inputs the message M into the tamper-proof device that is shown in Figure 4, The tamper-proof device uses Alice’s pseudo identity $PI{D}_A$, x and a current timestamp T to generate the signature $\sigma$ of M as

    $$\begin{array}{c}\hfill \sigma =P^{x+a}·H_2\left(M\right||PI{D}_A\left|\right|T)\end{array}$$
    Next, Alice obtains the final message $\{M,PI{D}_A,\sigma ,T\}$ and sends it to Bob.
• Verification Phase
  Given the final message $\{M,PI{D}_A,\sigma ,T\}$ sent by Alice, Bob uses the public parameters $\mathsf{PP}=(F_q,E|F_q,\mathbb{G},P,P_{pub},H_1,H_2)$ published by the $\mathcal{PSP}$ to check the validity of the signature as follows.
  • Step 1: For freshness, Bob repeats step 1 of the original verification of Scheme I.
  • Step 2: Bob verifies the signature by checking whether
    $\sigma \stackrel{?}{=}PI{D}_{A,1}·H_2\left(M\right||PI{D}_A\left|\right|T)P_{pub}$ holds or not. If it does, output is valid, otherwise output is ⊥.

5. Security Analysis

Considering the security requirements of an IoT-based payment system as a part of the system model of this article, in this section we discuss how these requirements can be achieved through both proposed protocols. The unforgeability property of each scheme is proved separately, while the other security properties are proved for both schemes together.

5.1. Correctness

For Scheme I, the correctness of signatures $\sigma =(U,V)$ is described as follows.

$$\begin{array}{cc}\hfill \widehat{e}(U,g_1)=& \widehat{e}(PI{D}_{A,1}·V·P_{pub},g_2)\hfill \\ \hfill =& \widehat{e}(g_1^x·V·g_1^a,g_2)\hfill \\ \hfill =& \widehat{e}(g_1^{x+a}·V,g_2)\hfill \\ \hfill =& \widehat{e}(g_2^{x+a}·V,g_1)\hfill \\ \hfill =& \widehat{e}(U,g_1)\hfill \end{array}$$

For Scheme II, the correctness of signatures $\sigma$ is described as follows.

$$\begin{array}{cc}\hfill \sigma & =PI{D}_{A,1}·H_2\left(M\right||PI{D}_A\left|\right|T)P_{pub}\hfill \\ & =P^x·H_2\left(M\right||PI{D}_A\left|\right|T)P_{pub}\hfill \\ & =P^x·H_2\left(M\right||PI{D}_A\left|\right|T)P^a\hfill \\ & =P^{x+a}·H_2\left(M\right||PI{D}_A\left|\right|T)\hfill \\ & =\sigma \hfill \end{array}$$

5.2. Security Proof Sketch

Theorem 1 (Unforgeability).

Only authorized users are allowed to make transactions. In other words, nobody can impersonate Alice or Bob to create a fake payment request or a fake or illegal receipt. Let $\mathcal{A}$ be a CDH attacker which attacks the IoT-based payment protocol and $\mathcal{F}$ be a forger who attacks the identity-based signature scheme (IBS). The forger $\mathcal{F}$ performs the IoT-based payment protocol instead of the $\mathcal{PSP}$ without knowing the $\mathcal{PSP}$’s secret master key.

Proof. 

Our Scheme I is existentially unforgeable against adaptive chosen message attacks in the Random Oracle Model if any adversary $\mathcal{A}$ with runtime t wins the game in detention with a probability at most ϵ after issuing at most q signing queries. Let $\mathcal{C}$ be a CDH attacker who receives a CDH challenge tuple ($g_1$, $g_1^a$, $g_1^b$) for $a,b\in {\mathbb{Z}}_q^{*}$ and $g_1\in \mathbb{G}$. $\mathcal{A}$ interacts with $\mathcal{C}$ as simulated in the game that is defined in detention 1. We show how $\mathcal{C}$ may use $\mathcal{A}$ to solve the CDH problem.

Initial. Firstly, $\mathcal{C}$ calculates $g_1^{ab}$ given $g_1^a$, $g_1^b$, for some unknown $a,b\in {\mathbb{Z}}_q^{*}$. $\mathcal{C}$ sets the public parameters including $P_{pub}=g_1^a$ and $g_2=g_1^b$. Finally, $\mathcal{C}$ gives $(g_1,g_2,P_{pub})$ to the $\mathcal{A}$.

Queries. In this phase, $\mathcal{C}$ answers $\mathcal{A}$’s oracle queries as follows:

• $H_2$ queries. $\mathcal{C}$ randomly chooses $j\in [1,q_{H_2}]$, where $q_{H_2}$ times $H_2$ queries. Whenever $\mathcal{A}$ requests the hash value of $\left(M_i\right|\left|PI{D}_{A_i}\right|\left|T_i\right)$ for $H_2$, $\mathcal{C}$ performs the following:
  • $\mathcal{C}$ saves a list $L^{list}$ which is initially empty.
  • $\mathcal{C}$ tests whether $i=j$, if the value of $\left(M_i\right|\left|PI{D}_{A_i}\right)$ already exists on the list $L^{list}$ in a tuple $\left(M_i\right|\left|PI{D}_{A_i}\right|\left|T_i\right|\left|h_i\right)$, then $\mathcal{C}$ outputs $h_i=H_2(M_i\left|\right|PI{D}_{A_i}\left|\right|T_i)$ as a response to $\mathcal{A}$’s query.
  • Otherwise, if $i\ne j$, $\mathcal{C}$ picks $h_i\in {\mathbb{Z}}_q^{*}$ and sets $h_i=H_2(M_i\left|\right|PI{D}_{A_i}\left|\right|T_i)$ and returns $h_i$ to $\mathcal{A}$.
• Sign queries. Once $\mathcal{C}$ receives a signing query for message $M_i$ from $\mathcal{A}$, $\mathcal{C}$ performs the following:
  • In spite of the fact that $\mathcal{C}$ does not know the private key, it can still produce the signature as follows. $\mathcal{C}$ looks for the tuple $\left(M_i\right|\left|PI{D}_{A_i}\right|\left|T_i\right|\left|h_i\right)$, if does not exist, $\mathcal{C}$ picks ${\alpha }_i,h_i\in {\mathbb{Z}}_q^{*}$ and $PI{D}_{A_i,2}\in \mathbb{G}$. It then produces the signature as $U=g_2^{{\alpha }_i}$ and $PI{D}_{A_i,1}=g_1^{{\alpha }_i}/h_i{P}_{pub}$. The validity of the produced signature $\{M_i,PI{D}_{A_i},{\sigma }_i=(U_i,h_i),T_i\}$ can be checked as follows.
    $\widehat{e}(PI{D}_{A_i,1}·h_i{P}_{pub},g_2)=\widehat{e}(g_1^{{\alpha }_i},g_2)=\widehat{e}(U_i,g_1)$.
  • If the tuple $\left(M_i\right|\left|PI{D}_{A_i}\right|\left|T_i\right|\left|h_i\right)$ already exists on the $L^{list}$, $\mathcal{C}$ picks another ${\alpha }_i,h_i\in {\mathbb{Z}}_q^{*}$ and $PI{D}_{A_i,2}\in \mathbb{G}$, and produces the signature again. It then returns
    $\{M_i,PI{D}_{A_i},{\sigma }_i,T_i\}$ to the $\mathcal{A}$ and saves the tuple $\left(M_i\right|\left|PI{D}_{A_i}\right||T_i,h_i)$ in the $L^{list}$. For the adversary $\mathcal{A}$, all signatures produced by $\mathcal{C}$ are indistinguishable from those signatures computed by the legitimate user.

Forgery. Eventually, $\mathcal{C}$ receives two valid forged signatures $\{PI{D}_{A_i},M_i^{*},{\sigma }_i,T_i\}$ and $\{PI{D}_{A_i},M_i^{*},{\sigma }_i^{*},T_i^{*}\}$ with the same random “α-value" but different hash values in a polynomial time, where

$${\sigma }_i=h_i·g_2^{{\alpha }_i+a}$$

(3)

$${\sigma }_i^{*}=h_i^{*}·g_2^{{\alpha }_i+a}$$

(4)

From (3) and (4), $\mathcal{C}$ obtains the following equation:

$$\begin{array}{c}\hfill {(h_i-h_i^{*})}^{-1}·({\sigma }_i-{\sigma }_i^{*})=g_2^a=g_1^{ab}\end{array}$$

Finally, $\mathcal{C}$ has successfully obtained the solution of the CDH problem. However, this breaks the assumption that the CDH is hard. It implies that an attacker cannot impersonate any customer or forge the signature on a payment receipt. Therefore, the unforgeability, nonrepudiation, and authenticity of payment receipt (message M) are achieved in our first proposed scheme. □

Proof. 

Our Scheme II is existentially unforgeable against adaptive chosen message attacks in the Random Oracle Model if and only if the DL is hard.

We describe how a challenger $\mathcal{C}$ can use an adversary $\mathcal{A}$ as a subroutine to solve a random given instance $(g_1,g_2)$ to compute $g_2=a{g}_1$ for a random $a\in {\mathbb{Z}}_q^{*}$ and $g_1,g_2\in \mathbb{G}$.

Initial.$\mathcal{C}$ picks a random integer $s\in {\mathbb{Z}}_q^{*}$ and sets $P_{pub}=s{g}_1$. $\mathcal{C}$ gives $(g_1,g_2,P_{pub})$ to the $\mathcal{A}$.

Queries. In this phase, $\mathcal{A}$ makes a sequence of oracle queries. These queries are answered by $\mathcal{C}$ as in the unforgeability game in detention 1.

• $H_1$ queries. $\mathcal{C}$ randomly picks $j\in [1,q_{H_1}]$, where $q_{H_1}$ times $H_1$ queries. Whenever $\mathcal{A}$ requests the hash value of $Q_i\in \mathbb{G}$ for $H_1$, $\mathcal{C}$ performs the following:
  • $\mathcal{C}$ keeps a list $L^{list}$ which is initially empty.
  • $\mathcal{C}$ tests whether $i=j$, if the value of $\left(Q_i\right|\left|h_{1,i}\right)$ already exists on the list $L^{list}$ in a tuple $\left(M_i\right|\left|PI{D}_{A_i}\right|\left|T_i\right|\left|Q_i\right|\left|h_{1,i}\right|\left|h_{2,i}\right)$, then $\mathcal{C}$ outputs $h_{1,i}=H_1\left(Q_i\right)$ as a response to the $\mathcal{A}$’s query.
  • Otherwise, if $i\ne j$, $\mathcal{C}$ picks $h_{1,i}\in {\mathbb{Z}}_q^{*}$ and sets $h_{1,i}=H_1\left(Q_i\right)$ and returns $h_{1,i}$ to $\mathcal{A}$.
• $H_2$ queries. When $\mathcal{A}$ requests the hash value of $\left(M_i\right|\left|PI{D}_{A_i}\right|\left|T_i\right)$ for $H_2$, $\mathcal{C}$ deals with this request as follows:
  • If the value of $\left(M_i\right|\left|PI{D}_{A_i}\right)$ already exists on the list $L^{list}$ in a tuple
    $\left(M_i\right|\left|PI{D}_{A_i}\right|\left|T_i\right|\left|Q_i\right|\left|h_{1,i}\right|\left|h_{2,i}\right)$, then $\mathcal{C}$ outputs $h_{2,i}=H_2(M_i\left|\right|PI{D}_{A_i}\left|\right|T_i)$ as a response to the $\mathcal{A}$’s query.
  • Otherwise, $\mathcal{C}$ picks $h_{2,i}\in {\mathbb{Z}}_q^{*}$ and sets $h_{2,i}=H_2(M_i\left|\right|PI{D}_{A_i}\left|\right|T_i)$ and returns $h_{2,i}$ to $\mathcal{A}$.
• Sign queries. Upon $\mathcal{C}$ receiving a query on message $M_i$, it randomly picks ${\alpha }_i,{\beta }_i,{\gamma }_i\in {\mathbb{Z}}_q^{*}$ and computes the signature as follows.

  $$\begin{array}{c}\hfill {\sigma }_i={\alpha }_i\end{array}$$

  $$\begin{array}{c}\hfill PI{D}_{A_i,2}=I{D}_{A_i}\oplus {\beta }_i\end{array}$$

  $$\begin{array}{c}\hfill PI{D}_{A_i,1}=g_1^{{\alpha }_i}/{\gamma }_i{P}_{pub}\end{array}$$
  The produced signature looks valid from $\mathcal{A}$’s view because

  $$\begin{array}{c}\hfill g_1^{{\sigma }_i}\\ \hfill =& PI{D}_{A_i,1}·{\gamma }_i{P}_{pub}\hfill \\ \hfill =& g_1^{{\alpha }_i}/{\gamma }_i{P}_{pub}·{\gamma }_i{P}_{pub}\hfill \\ \hfill =& g_1^{{\alpha }_i}=g_1^{{\sigma }_i}\hfill \end{array}$$

Forgery. According to the Forking Lemma [33], $\mathcal{C}$ can obtain two forged signatures, $\{PI{D}_{A_i},M_i^{*},{\sigma }_i,T_i\}$ and $\{PI{D}_{A_i},M_i^{*},{\sigma }_i^{*},T_i^{*}\}$. The forged signatures satisfy the following:

$${\sigma }_i=h_i^{({\alpha }_i+a)}$$

(5)

$${\sigma }_i^{*}=h_i^{*({\alpha }_i+a)}$$

(6)

From (5) and (6), $\mathcal{C}$ can obtain the solution of the given DL problem as follows.

$${(h_i-h_i^{*})}^{-1}·({\sigma }_i-{\sigma }_i^{*})=a$$

□

Theorem 2 (Anonymity of Scheme I and Scheme II).

In our proposed IoT-based payment schemes, Scheme I and II, the real identity of Alice is only known to the $\mathcal{PSP}$ and Alice herself. Alice should be able to deal with Bob without disclosing her real identity. The same holds true when Bob signs a receipt.

Proof. 

As shown in the pseudo identity generation module in Figure 2, Figure 4 and Step 3 during the payment phase, the real identity of Alice $I{D}_A$ is converted into two anonymous and random pseudo identities $PI{D}_A=(PI{D}_{A,1},PI{D}_{A,2})$ for unknown $x\in {\mathbb{Z}}_q^{*}$. Consequently, the only way to determine the the real identity from the anonymous and pseudo identity pair is to know the secret master key a from $P_{pub}$ or the private key x from $PI{D}_{A,1}$, as depicted in the traceability process below. Moreover, the anonymous identity pair $(PI{D}_{A,1},PI{D}_{A,2})$ is an ElGamal-type ciphertext, which is secure against chosen-plaintext attacks (CPAs). As a result, our proposed schemes provide the unconditional anonymity. □

Theorem 3 (Traceability).

When a dispute occurs during the payment process, the PSP should be able to identify the disputing parties; it then tries to resolve the dispute, in case none of the disputing parties is a malicious party. Otherwise, the malicious parties are revoked and kicked out of the payment protocol.

Proof. 

Given the anonymous identity pair $(PI{D}_{i,1},PI{D}_{i,2})$, only $\mathcal{PSP}$ can trace the real identity $I{D}_i$ of the user as follows.

$$\begin{array}{cc}\hfill PI{D}_{i,2}\oplus H_1\left(PI{D}_{i,1}^a\right)=& I{D}_i\oplus H_1\left(P_{pub}^x\right)\oplus H_1\left(PI{D}_{i,1}^a\right)\hfill \\ \hfill =& I{D}_i\oplus H_1\left(P^{x+a}\right)\oplus H_1\left(P^{a+x}\right)\hfill \\ \hfill =& I{D}_i\hfill \end{array}$$

It is clear that the $\mathcal{PSP}$ can easily trace the malicious users and find out their identities in order to revoke them from payment protocol. □

Theorem 4 (Revocation).

Malicious users must be prevented from accessing the tamper-proof device. Malicious users must be revoked and kicked out of payment protocol, but only by $\mathcal{PSP}$.

Proof. 

If misbehavior is detected, the identity of the violating user can be easily traced by $\mathcal{PSP}$, as shown in the proof of Theorem 3. The $\mathcal{PSP}$ then deletes the malicious user information $(I{D}_i,P{W}_i)$ from the tamper-proof device. Thus, the malicious users can be easily revoked and kicked out of payment protocol in our proposed schemes. □

Theorem 5 (Unlinkability).

For both schemes, any client can conduct multiple payment transactions without others being able to link these transactions to a particular client.

Proof.  

Each signature ${\sigma }_i$ on message $M_i$ partially consists of pseudo identity $PI{D}_i$ and timestamp $T_i$, which are changed every time. Furthermore, as shown in the proof of Theorem 2 and Theorem 3, it impossible to determine or even guess the real identity of a user from his/her anonymous identity without prior knowledge of the secret master key a and private key x. Therefore, there is no way to link two or more messages to a particular user, so the security property of unlinkability is achieved in both our schemes. □

Theorem 6 (Resistance to Impersonation Attack).

An adversary cannot impersonate Alice or Bob to create a fake payment request or a fake or illegal receipt.

Proof. 

Assume that an adversary attempts to send a valid payment request to Alice while impersonating as a legitimate merchant (Bob) to steal funds. To this end, it should generate the current timestamp and a signature for the message (payment request). However, to sign the message, the adversary needs to have the knowledge of the master secret key $a{\in }_R{\mathbb{Z}}_q^{*}$, private key x, and a current timestamp T. Any adversary cannot generate a valid payment request without these secrets. Similarly, no adversary can successfully impersonate the legitimate user (Alice). Thus, our protocols can resist the impersonation attack. □

Theorem 7 (Resistance to Replay Attack).

The previously transmitted payment request and receipt cannot be reused by adversaries to obtain the corresponding responses from the legitimate entity.

Proof. 

An adversary intends to prove its legitimate identity through delivering the previous valid signature of a legitimate entity to the receiver. However, in our protocol, this attack cannot be launched with success since the invalid timestamp condition results in the failure of authentication. Hence, our protocols can prevent the replay attack. □

Theorem 8 (Mutual Authentication).

In our protocols, mutual authentication allows the merchant (Bob) to return the confirmation message signed with its private key to the buyer (Alice) if the received signature is valid, and vice versa.

Proof. 

For Scheme I, given the final message $\{M,PI{D}_A,\sigma =(U,V),T\}$ sent by Alice, Bob uses the public parameters $\mathsf{PP}=(\mathbb{G},{\mathbb{G}}_T,q,\widehat{e},g_1,g_2,P_{pub},{\lambda }_1,H_1,H_2)$ published by the $\mathcal{PSP}$ to check the validity of the signature, as follows.

• Step 1: To resist the replaying attack, Bob checks the freshness of the final message. Assume that the receiving time is $T_B$. Bob checks whether $\Delta T\ge T_B-T$. If it does, then Bob continues; otherwise, he rejects it.
• Step 2: Bob verifies the signature by checking whether $\widehat{e}(U,g_1)\stackrel{?}{=}\widehat{e}(PI{D}_{A,1}·V·P_{pub},g_2)$ holds or not. If it does, output is valid, otherwise output is ⊥.

This verification can be performed as server-aided verification by the cloud server provider $\mathcal{CSP}$, as shown in Figure 3.

For Scheme II, given the final message $\{M,PI{D}_A,\sigma ,T\}$ sent by Alice, Bob uses the public parameters $\mathsf{PP}=(F_q,E|F_q,\mathbb{G},P,P_{pub},H_1,H_2)$ published by the $\mathcal{PSP}$ to check the validity of the signature as follows.

• Step 1: For freshness, Bob checks the freshness of the final message.
• Step 2: Bob verifies the signature by checking whether
  $\sigma \stackrel{?}{=}PI{D}_{A,1}·H_2\left(M\right||PI{D}_A\left|\right|T)P_{pub}$ holds or not. If it does, output is valid, otherwise output is ⊥.

□

6. Performance Evaluation

6.1. Computation Overhead

To experimentally evaluate the performance of the proposed IoT-based payment protocols, we adopt the following most commonly used IoT devices: smartphone (HUAWEI P9 Lite 2017), smartwatch (HUAWEI Watch 2), and embedded device Raspberry Pi 3 Model B. The specifications of these devices are shown in

Table 2. IoT devices specifications.

Device	Type	CPU	RAM	OS
HUAWEI Watch 2	Smartwatch	ARM Cortex-A7	768 MB	Android 7.0
HUAWEI P9 Lite 2017	Smartphone	Kirin 655	3 GB	Android 7.0
Raspberry Pi 3 Model B	IoT embedded board	ARM Cortex-A53	1 GB	Raspbian 9.3

. The performance evaluation is conducted based on the results in [34], in which the relative times of various cryptographic operations are averaged by repeated experiments in Java using the JPBC library [35].

For convenience, we adopt the following notations: $T_e$ for bilinear pairing and $T_{exp}$ for exponentiation on $\mathbb{G}$ (implemented as scalar multiplication of an elliptic-curve point). Multiplication and hash function operations are denoted by $T_{mul}$ and $T_{h(.)}$, respectively. The consuming times of these operations are shown in

Table 3. Cryptographic Operations time in IoT devices.

Operation	Time Computation [$\mathsf{\mu }$s]
	SmartWatch	Smartphone	Embedded Device
$T_{h(.)}$	176	85	479
$T_{mul}$	291	178	1743
$T_{exp}$	7521	5232	216269
$T_e$	1642230	1240235	3251354

Smartwatch: HUAWEI Watch 2; smartphone: HUAWEI P9 Lite 2017; and Pi 3: Raspberry Pi 3 Model B.

.

In the following, the efficiency of the proposed server-aided and pairing-free schemes are compared against each other and against the original scheme. From the efficiency comparison outlined in

Table 4. Efficiency comparison in smartwatch platform.

	Original Scheme ${}^{*}$		Scheme I ${}^{**}$		Scheme II ${}^{†}$
	Operation	Running Time [$\mathsf{\mu }$s]	Operation	Running Time [$\mathsf{\mu }$s]	Operation	Running Time [$\mathsf{\mu }$s]
Signing	$1T_E$	207	$1T_E$	207	$1T_E$	207
Total running time		207		207		207
Verifying	2$T_e$	3284460	3$T_{exp}$	22563	$1T_{h(.)}$	176
	2$T_{mul}$	582	3$T_{mul}$	873	$3T_{mul}$	873
Total running time in seconds		3285.052		23.436		1.049

${}^{*}$ Original scheme that performs the original verification process. ${}^{**}$ The proposed server-aided verification scheme. ${}^{†}$ The proposed pairing-free ECC-based scheme.

,

Table 5. Efficiency comparison in smartphone platform.

	Original Scheme ${}^{*}$		Scheme I ${}^{**}$		Scheme II ${}^{†}$
	Operation	Running Time [$\mathsf{\mu }$s]	Operation	Running Time [$\mathsf{\mu }$s]	Operation	Running Time [$\mathsf{\mu }$s]
	$1T_{h(.)}$	85	$1T_{h(.)}$	85	$1T_{h(.)}$	85
Signing	1$T_{mul}$	178	$1T_{mul}$	178	$1T_{mul}$	178
	1$T_{exp}$	5232	1$T_{exp}$	5232	1$T_{exp}$	5232
Total running time in seconds		5.495		5.49		5.49
Verifying	2$T_e$	2480470	3$T_{exp}$	15696	$1T_{h(.)}$	85
	2$T_{mul}$	356	3$T_{mul}$	534	$3T_{mul}$	534
Total running time in seconds		2480.826		16.23		0.619

${}^{*}$ Original scheme that performs the original verification process. ${}^{**}$ The proposed server-aided verification scheme. ${}^{†}$ The proposed pairing-free ECC-based scheme.

and

Table 6. Efficiency comparison in embedded device Raspberry Pi 1 Model B.

	Original Scheme ${}^{*}$		Scheme I ${}^{**}$		Scheme II ${}^{†}$
	Operation	Running Time [$\mathsf{\mu }$s]	Operation	Running Time [$\mathsf{\mu }$s]	Operation	Running Time [$\mathsf{\mu }$s]
	$1T_{h(.)}$	479	$1T_{h(.)}$	479	$1T_{h(.)}$	479
Signing	1$T_{mul}$	1743	$1T_{mul}$	1743	$1T_{mul}$	1743
	1$T_{exp}$	216269	1$T_{exp}$	216269	1$T_{exp}$	216269
Total running time in seconds		218.491		218.491		218.491
Verifying	2$T_e$	6502708	3$T_{exp}$	648807	$1T_{h(.)}$	479
	2$T_{mul}$	3486	3$T_{mul}$	5229	$3T_{mul}$	5229
Total running time in seconds		6506.194		654.036		5.708

${}^{*}$ Original scheme that performs the original verification process. ${}^{**}$ The proposed server-aided verification scheme. ${}^{†}$ The proposed pairing-free ECC-based scheme.

, we figure out that in each device, the computational complexity for all the schemes are similar at the signing stage. However, the difference appears clearly during the verification process. As indicated in Table 4, the total running times in the smartwatch platform of our schemes during the verification process are 23.436 s and 1.049 s for server-aided and pairing-free schemes, respectively, whereas the original scheme needs 3285.052 s at the same stage for the same device. From the results of the smartphone platform that are detailed in Table 5, our server-aided and pairing-free schemes only require 16.23 and 0.619 s for the verification process, against 2480.826 s for the original scheme at the same stage.

The results in Table 6 also indicate that, compared with the original scheme, the total running times of our schemes are reduced by approximately 10 times and up to 1140 times for server-aided and pairing-free schemes, respectively, in embedded device Raspberry Pi 1 Model B for the verification process. Figure 5a–c show the number of operations of our schemes versus the original scheme. It is worth mentioning that the original scheme is overshadowed by a heavy computational complexity of bilinear pairing operations.

6.2. Communication Overhead

The communication cost of our protocols and related payment protocols are analyzed in this subsection. We adopt the security level of 1024 bits RSA algorithm. In our experiment, we choose an Ate pairing $\widehat{e}:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$ since the size in bilinear pairing operation is 512 bit (64 bytes), and the modulus size of q in ECC operation is 512 bits (note that although the size of the elements in $\mathbb{G}$ is 160 × 16 = 2560 bits, the final size of one time scale multiplication on ECC should be 512 bits because of the modulus q). In addition, let the sizes of an identity, a timestamp, and a general hash function be 32 bits, 32 bits, and 160 bits. Then, an 8-character, 64-bit password is adopted in our protocols to defend against offline dictionary attacks. These parameters are summarized in

Table 7. Length of the group in bilinear pairing and ECC.

System	Carve	Pairing	Cyclic Group	$\left|\mathit{p}\right|,\left|\mathit{p}\right|$	$\left|\mathit{G}\right|$	Length of Elements
Bilinear Pairing	$y^2=x^3+1$	$\widehat{e}:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$	$\mathbb{G}\left(P\right)$	$\left|p\right|$ 512 bits	q 160 bits	$\left|\mathbb{G}\right|$1024 bits
ECC	$y^2=x^3+ax$	None	$\mathbb{G}\left(P\right)$	$\left|p\right|$ 160 bits	q 160 bits	$\left|\mathbb{G}\right|$320 bits

. The analysis process is shown below.

6.2.1. Scheme I (Server-Aided Verification Scheme)

• Registration phase:
  In this phase, $\mathcal{PSP}$ assigns real identities $I{D}_A,I{D}_B\in \mathbb{G}$ and passwords $P{W}_A$ and $P{W}_B$ for Alice and Bob, respectively. The overhead of these messages are $2\left|\mathbb{G}\right|=2\ast 1024+2\ast 64=2176$ bits = 272 bytes.
• Payment phase:
  In the payment phase, Alice send the tuple $\{M,PI{D}_A,\sigma =(U,V),T\}$ to Bob. From this tuple $PI{D}_A,U,V\in \mathbb{G}$. Therefore, the communication cost for this phase is $3\left|\mathbb{G}\right|+32=3\ast 1024+32+256=3160$ bits = 395 bytes
• Server-aided verification
  In this phase, Bob sends the message and blind signature $\{PI{D}_{A,1},{\sigma }^{\prime }=(U^{\prime },V^{\prime }),T\}$ to the $\mathcal{CSP}$, and he receives ${\lambda }_2,{\lambda }_3$ from $\mathcal{CSP}$. In these transmitted messages,
  $PI{D}_{A,1},U^{\prime },V^{\prime }\in \mathbb{G}$ and ${\lambda }_2,{\lambda }_3$ are $2\left|p\right|,\left|p\right|$. Hence, the communication overheads in this phase are $3\left|\mathbb{G}\right|+2\left|p\right|,\left|p\right|=3\ast 1024+2\ast 512=4,096$ bits = 512 bytes.

6.2.2. Scheme II (Pairing-Free ECC-Based Scheme)

• Registration phase:
  In this phase, $\mathcal{PSP}$ assigns real identities $I{D}_A,I{D}_B\in \mathbb{G}$ and passwords $P{W}_A$ and $P{W}_B$ for Alice and Bob, respectively. The overheads of these messages are $2\left|\mathbb{G}\right|=2\ast 320+2\ast 64=704$ bits = 88 bytes.
• Payment phase:
  In the payment phase, Alice send the tuple $\{M,PI{D}_A,\sigma ,T\}$ to Bob. From this tuple $PI{D}_A,\sigma \in \mathbb{G}$. Therefore, the communication cost for this phase is $2\left|\mathbb{G}\right|+32=2\ast 320+32=672$ bits = 84 bytes.

To sum up, the overall communication overheads of our schemes are summarized in the

Table 8. Comparison of communication costs (in bytes).

Scheme	Send a Single Message	Send n Single Messages
Zeng et al. [36]	172 + 132 + 328 + 20=625	$652n$
Thammarat [37]	424 + 152 + 448 + 243 + 484 + 243 = 1958	$1958n$
Our Scheme I	272 + 395 + 512 = 1179	$1179n$
Our Scheme II	84 + 88 = 172	$172n$

. As shown in this table, our proposed schemes have certain advantages in communication overhead. Specifically, our Scheme II incurs lower communication overhead in comparison with the other two schemes [36,37]. Our Scheme I is slightly more than Zeng et al.’s [36] scheme, but significantly less than Thammarat’s [37]. Furthermore, in our Scheme I, communication–computation trade-off is provided. As the processing capabilities of IoT devices is extremely limited, we adopt a server-aided verification technique to outsource the heavy computation overhead on the sensor node to a cloud server. This technique decreased the computation overhead by 89% in the Raspberry Pi 3 Model B, and 99% in the smartphone and smartwatch, but on the other hand, the communication overhead increased by 56%.

6.3. Storage Overhead

In general, sensor node, IoT devices, and smartcard have far less storage capacity than the payment service provider ($\mathcal{PSP}$). Therefore, reduction of the requirements of the storage capacity of sensor node and IoT devices is essential for IoT-based applications. We kept this issue in mind when designing our IoT-based payment protocols. To this end, in the initialization phase, $\mathcal{PSP}$ stores $(a,I{D}_A,I{D}_B,P{W}_A,P{W}_B)$. These parameters are equivalent to $2\left|\mathbb{G}\right|+|{\mathbb{Z}}_q^{*}|+2\ast 64$ bit, while sensor node stores nothing in its memory during all stages of the protocol, but the user needs to memorize the password.

7. Conclusions

This paper raises the challenging question of how to increase convenience and enable clients to derive maximum benefits and to enjoy the appealing features of IoT-based payment systems. To answer this question, we proposed two lightweight and secure IoT-based payment protocols based on the identity-based signature scheme. The security analysis demonstrates that the proposed protocols are provably secure in the Random Oracle Model under the discrete logarithm and computational Diffie–Hellman assumptions. In addition, the performance evaluation results show that the proposed protocols have lower computational and communication costs, which will enable us to satisfy the IoT-based payment system’s goal of conserving bandwidth consumption, energy, and processing power. The long-term results of this effort are to continue to improve the communication and computation costs at the sensor node.