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

^{1}

^{2}

## Abstract

**:**

## 1. Introduction

#### 1.1. Motivations

#### 1.2. Contribution

- 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.

## 2. Related Work

#### 2.1. Electronic Payment Systems

#### 2.2. Contactless Payment

#### 2.3. Mobile Wallet

## 3. Preliminaries

#### 3.1. System Model

- 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.

#### 3.2. Elliptic Curves Cryptography (ECC)

#### 3.3. Bilinear Pairing

- 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})\xb7\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

- 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

**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.

## 4. Proposed Schemes

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

- Initialization PhaseIn 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 PhaseAccording 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\xb7{g}_{2}^{x+a}$.

Afterward, Alice obtains the final $\{M,PI{D}_{A},\sigma =(U,V),T\}$ and sends it to Bob.

- Verification PhaseUpon 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}\xb7V\xb7{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\xb7{g}_{1}^{r}$ and ${V}^{\prime}=V\xb7{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}\xb7{P}_{pub},{V}^{\prime})$. It then sends ${\lambda}_{2},{\lambda}_{3}$ to Bob.
- Step 4: Bob checks if ${\lambda}_{2}\stackrel{?}{=}{\lambda}_{3}^{-t}\xb7{\lambda}_{1}^{r}$. If it does, output is valid, otherwise output is ⊥.

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

**Scheme I**: the initialization phase, the payment phase, and the verification phase.

- Initialization phaseInitially, 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 PhaseSteps 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}\xb7{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 PhaseGiven 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}\xb7{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

#### 5.1. Correctness

#### 5.2. Security Proof Sketch

**Theorem 1**(Unforgeability).

**Proof.**

**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 \text{}[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}\xb7{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

**Proof.**

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

**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 \text{}[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}\xb7{\gamma}_{i}{P}_{pub}\hfill \\ \hfill =& {g}_{1}^{{\alpha}_{i}}/{\gamma}_{i}{P}_{pub}\xb7{\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:

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

**Proof**

**.**

**Theorem 3**(Traceability).

**Proof**

**.**

**Theorem 4**(Revocation).

**Proof**

**.**

**Theorem 5**(Unlinkability).

**Proof**

**.**

**Theorem 6**(Resistance to Impersonation Attack).

**Proof**

**.**

**Theorem 7**(Resistance to Replay Attack).

**Proof**

**.**

**Theorem 8**(Mutual Authentication).

**Proof**

**.**

**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}\xb7V\xb7{P}_{pub},{g}_{2})$ holds or not. If it does, output is valid, otherwise output is ⊥.

**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}\xb7{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

#### 6.2. Communication Overhead

#### 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.

#### 6.3. Storage Overhead

## 7. Conclusions

## Funding

## Institutional Review Board Statement

## Informed Consent Statement

## Data Availability Statement

## Conflicts of Interest

## References

- Qin, Z.; Sun, J.; Wahaballa, A.; Zheng, W.; Xiong, H.; Qin, Z. A Secure and Privacy-preserving Mobile Wallet with Outsourced Verification in Cloud Computing. Comput. Stand. Interfaces
**2017**, 54, 55–60. [Google Scholar] [CrossRef] - Turban, E.; Outland, J.; King, D.; Lee, J.K.; Liang, T.P.; Turban, D.C. Mobile commerce and the internet of things. In Electronic Commerce; Springer: Cham, Switzerland, 2018; pp. 205–248. [Google Scholar]
- Cha, B.R.; Lee, S.H.; Park, S.B.; Ji, Y.; Lee, G.K. Design of micro-payment to strengthen security by 2 factor authentication with mobile & wearable devices. Adv. Sci. Technol. Lett.
**2015**, 109, 28–32. [Google Scholar] - Zhou, T.T.; Zhou, D.T.; Zhou, A.H. One-Touch Payment Using Haptic Control via a Messaging and Calling Multimedia System on Mobile Device and Wearable Device, Currency Token Interface, Point of Sale Device, and Electronic Payment Card. U.S. Patent 8,985,442, 24 March 2015. [Google Scholar]
- Bhardwaj, A.; Kaushik, K.; Kumar, M. Taxonomy of Security Attacks on Internet of Things. In Security and Privacy in Cyberspace; Kaiwartya, O., Kaushik, K., Gupta, S.K., Mishra, A., Kumar, M., Eds.; Springer Nature: Singapore, 2022; pp. 1–24. [Google Scholar] [CrossRef]
- Wheelus, C.; Zhu, X. IoT network security: Threats, risks, and a data-driven defense framework. IoT
**2020**, 1, 259–285. [Google Scholar] [CrossRef] - Rivest, R.L.; Shamir, A.; Adleman, L. A Method for Obtaining Digital Signatures and Public-key Cryptosystems. Commun. ACM
**1978**, 21, 120–126. [Google Scholar] [CrossRef] [Green Version] - Paterson, K. ID-based signatures from pairings on elliptic curves. Electron. Lett.
**2002**, 38, 1025–1026. [Google Scholar] [CrossRef] [Green Version] - Hess, F. Efficient Identity Based Signature Schemes Based on Pairings. In Proceedings of the Revised Papers from the 9th Annual International Workshop on Selected Areas in Cryptography, SAC ’02, St. Johns, NL, Canada, 15–16 August 2002; Springer: London, UK, 2003; pp. 310–324. [Google Scholar]
- Chen, C.C.; Liao, C.C. Research on the development of Fintech combined with AIoT. In Proceedings of the 2021 IEEE International Conference on Consumer Electronics-Taiwan (ICCE-TW), Penghu, Taiwan, 15–17 September 2021; pp. 1–2. [Google Scholar] [CrossRef]
- Chen, S.; Su, T.; Fan, L.; Meng, G.; Xue, M.; Liu, Y.; Xu, L. Are mobile banking apps secure? What can be improved? In Proceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, Lake Buena Vista, FL, USA, 4–9 November 2018; pp. 797–802. [Google Scholar]
- Hassan, M.A.; Shukur, Z.; Hasan, M.K. An efficient secure electronic payment system for e-commerce. Computers
**2020**, 9, 66. [Google Scholar] [CrossRef] - Wang, F.; Yang, N.; Shakeel, P.M.; Saravanan, V. Machine learning for mobile network payment security evaluation system. Trans. Emerg. Telecommun. Technol.
**2021**, e4226. [Google Scholar] [CrossRef] - Deng, X.; Gao, T. Electronic payment schemes based on blockchain in VANETs. IEEE Access
**2020**, 8, 38296–38303. [Google Scholar] [CrossRef] - Tut, D. FinTech and the Covid-19 pandemic: Evidence from electronic payment systems. SSRN
**2020**. [Google Scholar] [CrossRef] - Shanmugapriyan, J.; Parthasarathy, R.; Sathish, S.; Prasanth, S. Secure Electronic Transaction Using AADHAAR Based QR Code and Biometric Authentication. In Proceedings of the 2022 International Conference on Communication, Computing and Internet of Things (IC3IoT), Chennai, India, 10–11 March 2022; IEEE: Piscataway, NJ, USA, 2022; pp. 1–4. [Google Scholar]
- Basin, D.; Sasse, R.; Toro-Pozo, J. The EMV Standard: Break, Fix, Verify. In Proceedings of the 2021 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 24–27 May 2021; pp. 1766–1781. [Google Scholar] [CrossRef]
- Gupta, B.B.; Narayan, S. A key-based mutual authentication framework for mobile contactless payment system using authentication server. J. Organ. End User Comput. (JOEUC)
**2021**, 33, 1–16. [Google Scholar] [CrossRef] - Nilsson, H. Trust issues? The need to secure contactless biometric payment cards. Biom. Technol. Today
**2021**, 2021, 5–8. [Google Scholar] [CrossRef] - Liao, Y.; He, Y.; Li, F.; Zhou, S. Analysis of a mobile payment protocol with outsourced verification in cloud server and the improvement. Comput. Stand. Interfaces
**2018**, 56, 101–106. [Google Scholar] [CrossRef] - Yeh, K.H. A secure transaction scheme with certificateless cryptographic primitives for IoT-based mobile payments. IEEE Syst. J.
**2017**, 12, 2027–2038. [Google Scholar] [CrossRef] - Chen, Y.; Xu, W.; Peng, L.; Zhang, H. Light-weight and privacy-preserving authentication protocol for mobile payments in the context of IoT. IEEE Access
**2019**, 7, 15210–15221. [Google Scholar] [CrossRef] - Qiao, Z.; Yang, Q.; Zhou, Y.; Zhang, M. Improved Secure Transaction Scheme With Certificateless Cryptographic Primitives for IoT-Based Mobile Payments. IEEE Syst. J.
**2022**, 16, 1842–1850. [Google Scholar] [CrossRef] - Xiong, H.; Wu, Y.; Jin, C.; Kumari, S. Efficient and Privacy-Preserving Authentication Protocol for Heterogeneous Systems in IIoT. IEEE Internet Things J.
**2020**, 7, 11713–11724. [Google Scholar] [CrossRef] - Şengel, Ö.; Aydin, M.A.; Sertbaş, A. A survey on white box cryptography model for mobile payment systems. In International Telecommunications Conference; Springer: Berlin/Heidelberg, Germany, 2019; pp. 215–225. [Google Scholar]
- Li, S.; Hu, X.; Fengling; Zhang, Y.; Dong, W.; Ye, J.; Sun, H. Research on Offline Transaction Model in Mobile Payment System. In International Conference on Frontier Computing; Hung, J.C., Yen, N.Y., Hui, L., Eds.; Springer: Singapore, 2019; pp. 1815–1820. [Google Scholar]
- Miller, V.S. Use of elliptic curves in cryptography. In Proceedings of the Advances in Cryptology CRYPTO 85 Proceedings, Santa Barbara, CA, USA, 18–22 August 1985; Springer: Berlin/Heidelberg, Germany, 1985; pp. 417–426. [Google Scholar]
- Koblitz, N. Elliptic curve cryptosystems. Math. Comput.
**1987**, 48, 203–209. [Google Scholar] [CrossRef] - Bos, J.W.; Halderman, J.A.; Heninger, N.; Moore, J.; Naehrig, M.; Wustrow, E. Elliptic curve cryptography in practice. In International Conference on Financial Cryptography and Data Security; Springer: Berlin/Heidelberg, Germany, 2014; pp. 157–175. [Google Scholar]
- Tzeng, S.F.; Horng, S.J.; Li, T.; Wang, X.; Huang, P.H.; Khan, M.K. Enhancing Security and Privacy for Identity-Based Batch Verification Scheme in VANETs. IEEE Trans. Veh. Technol.
**2016**, 66, 3235–3248. [Google Scholar] [CrossRef] - Hu, X.; Wang, J.; Xu, H.; Liu, Y.; Zhang, X. Secure and Pairing-Free Identity-Based Batch Verification Scheme in Vehicle Ad-Hoc Networks. In Proceedings of the Intelligent Computing Methodologies: 12th International Conference, ICIC 2016, Lanzhou, China, 2–5 August 2016; Proceedings, Part III. Huang, D.S., Han, K., Hussain, A., Eds.; Springer International Publishing: Cham, Switzerland, 2016; pp. 11–20. [Google Scholar]
- Xu, L.; Li, J.; Tang, S.; Baek, J. Server-Aided Verification Signature with Privacy for Mobile Computing. Mob. Inf. Syst.
**2015**, 1–11. [Google Scholar] [CrossRef] [Green Version] - Pointcheval, D.; Stern, J. Security Arguments for Digital Signatures and Blind Signatures. J. Cryptol.
**2000**, 13, 361–396. [Google Scholar] [CrossRef] - Malina, L.; Hajny, J.; Martinasek, Z. Privacy-preserving authentication systems using smart devices. In Proceedings of the 2016 39th International Conference on Telecommunications and Signal Processing (TSP), Vienna, Austria, 27–29 June 2016; pp. 11–14. [Google Scholar] [CrossRef]
- De Caro, A.; Iovino, V. jPBC: Java pairing based cryptography. In Proceedings of the 16th IEEE Symposium on Computers and Communications, ISCC 2011, Corfu, Greece, 28 June–1 July 2011; pp. 850–855. [Google Scholar]
- Zeng, X.; Xu, G.; Zheng, X.; Xiang, Y.; Zhou, W. E-AUA: An efficient anonymous user authentication protocol for mobile IoT. IEEE Internet Things J.
**2018**, 6, 1506–1519. [Google Scholar] [CrossRef] - Thammarat, C. Efficient and secure NFC authentication for mobile payment ensuring fair exchange protocol. Symmetry
**2020**, 12, 1649. [Google Scholar] [CrossRef]

**Figure 5.**(

**a**) Efficiency comparison in smartwatch platform; (

**b**) efficiency comparison in smartphone platform; (

**c**) efficiency comparison in embedded device Raspberry Pi 1 Model B.

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) |

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 |

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 |

Original Scheme ${}^{*}$ | Scheme I ${}^{**}$ | Scheme II ${}^{\u2020}$ | ||||
---|---|---|---|---|---|---|

Operation | Running Time [$\mathsf{\mu}$s] | Operation | Running Time [$\mathsf{\mu}$s] | Operation | Running Time [$\mathsf{\mu}$s] | |

Signing | $1{T}_{E}$ | 207 | $1{T}_{E}$ | 207 | $1{T}_{E}$ | 207 |

Total running time | 207 | 207 | 207 | |||

Verifying | 2${T}_{e}$ | 3284460 | 3${T}_{exp}$ | 22563 | $1{T}_{h(.)}$ | 176 |

2${T}_{mul}$ | 582 | 3${T}_{mul}$ | 873 | $3{T}_{mul}$ | 873 | |

Total running time in seconds | 3285.052 | 23.436 | 1.049 |

Original Scheme ${}^{*}$ | Scheme I ${}^{**}$ | Scheme II ${}^{\u2020}$ | ||||
---|---|---|---|---|---|---|

Operation | Running Time [$\mathsf{\mu}$s] | Operation | Running Time [$\mathsf{\mu}$s] | Operation | Running Time [$\mathsf{\mu}$s] | |

$1{T}_{h(.)}$ | 85 | $1{T}_{h(.)}$ | 85 | $1{T}_{h(.)}$ | 85 | |

Signing | 1${T}_{mul}$ | 178 | $1{T}_{mul}$ | 178 | $1{T}_{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 | $1{T}_{h(.)}$ | 85 |

2${T}_{mul}$ | 356 | 3${T}_{mul}$ | 534 | $3{T}_{mul}$ | 534 | |

Total running time in seconds | 2480.826 | 16.23 | 0.619 |

Original Scheme ${}^{*}$ | Scheme I ${}^{**}$ | Scheme II ${}^{\u2020}$ | ||||
---|---|---|---|---|---|---|

Operation | Running Time [$\mathsf{\mu}$s] | Operation | Running Time [$\mathsf{\mu}$s] | Operation | Running Time [$\mathsf{\mu}$s] | |

$1{T}_{h(.)}$ | 479 | $1{T}_{h(.)}$ | 479 | $1{T}_{h(.)}$ | 479 | |

Signing | 1${T}_{mul}$ | 1743 | $1{T}_{mul}$ | 1743 | $1{T}_{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 | $1{T}_{h(.)}$ | 479 |

2${T}_{mul}$ | 3486 | 3${T}_{mul}$ | 5229 | $3{T}_{mul}$ | 5229 | |

Total running time in seconds | 6506.194 | 654.036 | 5.708 |

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 |

Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |

© 2022 by the author. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Wahaballa, A.
Lightweight and Secure IoT-Based Payment Protocols from an Identity-Based Signature Scheme. *Electronics* **2022**, *11*, 3445.
https://doi.org/10.3390/electronics11213445

**AMA Style**

Wahaballa A.
Lightweight and Secure IoT-Based Payment Protocols from an Identity-Based Signature Scheme. *Electronics*. 2022; 11(21):3445.
https://doi.org/10.3390/electronics11213445

**Chicago/Turabian Style**

Wahaballa, Abubaker.
2022. "Lightweight and Secure IoT-Based Payment Protocols from an Identity-Based Signature Scheme" *Electronics* 11, no. 21: 3445.
https://doi.org/10.3390/electronics11213445