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

Abubaker Wahaballa

Computer Science Department, Mihareeba Technological College, Sudan Technological University (STU), Khartoum 11111, Sudan

Submission received: 21 September 2022 / Revised: 20 October 2022 / Accepted: 21 October 2022 / Published: 25 October 2022

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:

Payment Service Provider ( PSP ): Responsible for ensuring payment security and privacy. The PSP performs cryptographic initialization and user management.

Cloud server provider ( 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 PSP and 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 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.

where a , b , x , y ∈ F q with the discriminant ▵ = ( 4 a 2 + 27 b 2 ) mod q ≠ 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 O (called point at infinity) form an additive cyclic group G , that is, G = < ( x , y ) : a , b , x , y ∈ F q and ( x , y ) ∈ E q ( a , b ) >⋃ < O >of prime order q . Scalar multiplication over E | F q can be computed as follows:

3.3. Bilinear Pairing

Let G and G T be two cyclic groups of the same large prime q . Let g 1 be generators of G . Assume that the discrete logarithm in G and G T are hard. Let e ^ : G × G → G T be an admissible pairing that satisfies the following properties:

e ^ ( a g 1 , b g 2 ) = e ^ ( g 1 , g 2 ) a b = e ^ ( g 1 , b g 2 ) a = e ^ ( a g 1 , g 2 ) b = e ^ ( a b g 1 , g 2 ) = e ^ ( g 1 , a b g 2 ) .

Non-degenerate : There exists g 1 , g 2 ∈ G such that e ^ ( g 1 , g 2 ) ≠ 1 . This means that if g 1 and g 2 are two generators of G , then e ^ ( g 1 , g 2 ) is a generator of G T .

3.4. Computational Hardness Assumption

Discrete logarithm (DL) problem: Given a generator g 1 of a cyclic group G * with order q , then compute g 2 = g 1 a for a random a ∈ Z q * .

Computational Diffie–Hellman (CDH) problem: Given ( g , g a , g b ) then compute g a b , where g ∈ G is the generator and a , b ∈ 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 A be a CDH attacker which attacks the IoT-based payment protocol and F be a forger who attacks the identity-based signature scheme (IBS). The forger F performs the IoT-based payment protocol instead of the PSP without knowing the PSP ’s secret master key. The attacker A plays the following game with F .

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

Sign query: Signature oracle: produces signatures on arbitrary messages using the private key corresponding to arbitrary identities.

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

Anonymity: The real identity of Alice is only known to the 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 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 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.

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

In this phase, the PSP initializes and assigns the system parameters for each user. These include two groups, G and G T , of prime order q and a bilinear pairing e ^ : G × G → G T . Let g 1 and g 2 denote two generators in G . It next randomly selects its secret master key a ∈ R Z q * and computes its public master key P p u b = g 1 a . It also selects two hash functions, H 1 and H 2 . For the first registration of Alice and Bob, PSP assigns real identities I D A , I D B ∈ G and passwords P W A and P W B for Alice and Bob, respectively. PSP then stores ( a , I D A , I D B , P W A , P W B ) into the tamper-proof device. Finally, PSP announces the public parameters: PP = ( G , G T , q , e ^ , g 1 , g 2 , P p u b , λ 1 , H 1 , H 2 ) , where λ 1 = e ^ ( g 1 , g 1 ) .

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 P I D A into P I D A , 1 and P I D A , 2 . It then picks x ∈ Z q * and computes the pseudo identity P I D A as follows:

Finally, the pseudo identity generation module sets Alice’s pseudo identity as P I D A = ( P I D A , 1 , P I D A , 2 ) .

Step 4: Alice inputs the message M into the tamper-proof device. The tamper-proof device uses Alice’s pseudo identity P I D A , x and a current timestamp T to generate the signature σ of M as follows:

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.

Original verification : Given the final message < M , P I D A , σ = ( U , V ) , T >sent by Alice, Bob uses the public parameters PP = ( G , G T , q , e ^ , g 1 , g 2 , P p u b , λ 1 , H 1 , H 2 ) published by the 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 Δ T ≥ T B − T . If it does, then Bob continues; otherwise, he rejects it.

Step 2: Bob verifies the signature by checking whether e ^ ( U , g 1 ) = ? e ^ ( P I D A , 1 · V · P p u b , g 2 ) holds or not. If it does, output is valid, otherwise output is ⊥.

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 CSP to perform server-aided verification. The following steps and Figure 3 illustrate how Bob and 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 PP = ( G , G T , q , e ^ , g 1 , g 2 , P p u b , λ 1 , H 1 , H 2 ) and the final message < M , P I D A , σ = ( U , V ) , T >, Bob randomly chooses r , t ∈ Z q * and computes U ′ = U · g 1 r and V ′ = V · g 2 t . He then sets σ ′ = ( U ′ , V ′ ) . Afterward, he sends the message and blind signature < P I D A , 1 , σ ′ , T >to the CSP .

Step 3: Upon the CSP receiving < P I D A , 1 , σ ′ , T >from Bob, it computes λ 2 = e ^ ( U ′ , g 1 ) and λ 3 = e ^ ( P I D A , 1 · P p u b , V ′ ) . It then sends λ 2 , λ 3 to Bob.

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.

< F q , E | F q , G , P >as defined in Section 3.2. Then, it picks the secret master key a ∈ Z q * and computes its public master key P p u b = P a . Next, PSP chooses two hash functions, H 1 and H 2 . Finally, the PSP publishes the system parameters: PP = ( F q , E | F q , G , P , P p u b , H 1 , H 2 ) .

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 P I D A into P I D A , 1 and P I D A , 2 . It then picks x ∈ Z q * and computes pseudo identity P I D A as follows:

Finally, the pseudo identity generation module sets Alice’s pseudo identity as P I D A = ( P I D A , 1 , P I 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 P I D A , x and a current timestamp T to generate the signature σ of M as

Given the final message < M , P I D A , σ , T >sent by Alice, Bob uses the public parameters PP = ( F q , E | F q , G , P , P p u b , H 1 , H 2 ) published by the PSP to check the validity of the signature as follows.

σ = ? P I D A , 1 · H 2 ( M | | P I D A | | T ) P p u b 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

e ^ ( U , g 1 ) = e ^ ( P I D A , 1 · V · P p u b , g 2 ) = e ^ ( g 1 x · V · g 1 a , g 2 ) = e ^ ( g 1 x + a · V , g 2 ) = e ^ ( g 2 x + a · V , g 1 ) = e ^ ( U , g 1 )

σ = P I D A , 1 · H 2 ( M | | P I D A | | T ) P p u b = P x · H 2 ( M | | P I D A | | T ) P p u b = P x · H 2 ( M | | P I D A | | T ) P a = P x + a · H 2 ( M | | P I D A | | T ) = σ

5.2. Security Proof Sketch

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 A be a CDH attacker which attacks the IoT-based payment protocol and F be a forger who attacks the identity-based signature scheme (IBS). The forger F performs the IoT-based payment protocol instead of the PSP without knowing the PSP ’s secret master key.

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

Initial. Firstly, C calculates g 1 a b given g 1 a , g 1 b , for some unknown a , b ∈ Z q * . C sets the public parameters including P p u b = g 1 a and g 2 = g 1 b . Finally, C gives ( g 1 , g 2 , P p u b ) to the A .

H 2 queries. C randomly chooses j ∈ [ 1 , q H 2 ] , where q H 2 times H 2 queries. Whenever A requests the hash value of ( M i | | P I D A i | | T i ) for H 2 , C performs the following:

C tests whether i = j , if the value of ( M i | | P I D A i ) already exists on the list L l i s t in a tuple ( M i | | P I D A i | | T i | | h i ) , then C outputs h i = H 2 ( M i | | P I D A i | | T i ) as a response to A ’s query.

Otherwise, if i ≠ j , C picks h i ∈ Z q * and sets h i = H 2 ( M i | | P I D A i | | T i ) and returns h i to A .

In spite of the fact that C does not know the private key, it can still produce the signature as follows. C looks for the tuple ( M i | | P I D A i | | T i | | h i ) , if does not exist, C picks α i , h i ∈ Z q * and P I D A i , 2 ∈ G . It then produces the signature as U = g 2 α i and P I D A i , 1 = g 1 α i / h i P p u b . The validity of the produced signature < M i , P I D A i , σ i = ( U i , h i ) , T i >can be checked as follows.

If the tuple ( M i | | P I D A i | | T i | | h i ) already exists on the L l i s t , C picks another α i , h i ∈ Z q * and P I D A i , 2 ∈ G , and produces the signature again. It then returns

< M i , P I D A i , σ i , T i >to the A and saves the tuple ( M i | | P I D A i | | T i , h i ) in the L l i s t . For the adversary A , all signatures produced by C are indistinguishable from those signatures computed by the legitimate user.

Forgery. Eventually, C receives two valid forged signatures < P I D A i , M i * , σ i , T i >and < P I D A i , M i * , σ i * , T i * >with the same random “α-value" but different hash values in a polynomial time, where