You are currently viewing a new version of our website. To view the old version click .
Applied Sciences
  • Article
  • Open Access

29 March 2021

PetroBlock: A Blockchain-Based Payment Mechanism for Fueling Smart Vehicles

,
,
,
,
and
1
Department of Computer Engineering, Jeju National University, Jejusi 63243, Korea
2
College of CIT, Taif University, P.O. Box 11099, Taif 21944, Saudi Arabia
3
Department of Electronic Engineering, Jeju National University, Jejusi 63243, Korea
4
Computer Science, Robotics and Internet of Things Lab of Prince Sultan University, Riyadh 12435, Saudi Arabia
This article belongs to the Special Issue Advances in Blockchain Technology and Applications II

Abstract

Current developments in information technology and increased inclination towards smart cities have led to the initiation of a plethora of features by technology-oriented companies (i.e., car manufacturers) to improve users’ privacy and comfort. The invention of smart vehicle technology paved the way for the excessive use of machine-to-machine technologies. Moreover, third-party sharing of financial services are also introduced that support machine-to-machine (M2M) communication. These monetary systems’ prime focus is on improving reliability and security; however, they overlook aspects like behaviors and users’ need. For instance, people often hand over their bank cards or share their credentials with their colleagues to withdraw money on their behalf. Such behaviors may originate issues about privacy and security that can have severe losses for the card owner. This paper presents a novel blockchain-based strategy for payment of fueling of smart cars without any human interaction while maintaining transparency, privacy, and trust. The proposed system is capable of data sharing among the users of the system while securing sensitive information. Moreover, we also provide a blockchain-based secure privacy-preserving strategy for payment of fueling among the fuel seller and buyer without human intervention. Furthermore, we have also analytically evaluated several experiments to determine the proposed blockchain platform’s usability and efficiency. Lastly, we harness Hyperledger Caliper to assess the proposed system’s performance in terms of transaction latency, transactions per second, and resource consumption.

1. Introduction

The emergence of Internet of Things (IoT) technologies plays a vital role in various walks of human life, including business, agriculture, healthcare, transport, etc. According to Cisco and Ericsson, the quantity of IoT devices in daily usage will exceed over 100 billion by 2020 []. IoT devices, i.e., smart mirrors, smart cameras, smart cars, smartphones, etc., connect a user with a diverse range of services like traveling, manufacturing, transactions, etc., by harnessing the Internet. Most of these IoT devices depend upon machine-to-machine (M2M) communication, which involves communication without humans’ intervention. The M2M communication-based systems are capable of automating the process transaction through online payment systems []. Although M2M communication transactions are broadly being harnessed across the globe, the context data in M2M communication have a severe concern regarding security and privacy. The contemporary M2M-based applications face three significant challenges: (i) transparency, (ii) interoperability, and (iii) trust []. Transparency is one of the most significant issues faced by IoT and M2M-based applications. The current IoT and M2M devices are highly insecure in nature; therefore, communication among them must be secured by employing different encryption techniques. Moreover, data ownership is also non-persistent in these devices. Encrypting IoT and M2M infrastructure involves huge complexity. Interconnection among peripherals enhances productivity in industrial settings as well as residential area. However, when the quantity of devices increases and network connections expand due to increased population, the issue of interoperability arises. The third challenge involves the trust of users. Figure 1 illustrates an example of M2M communication wherein a smart vehicle uses limited-range wireless communication (e.g., Bluetooth and NFC) to make payment for refueling while the user of the smart car trusts vendor by providing credit card information. The smart car and gas station are equipped with IoT applications that hold the digital wallet of a user.
Figure 1. A typical smart pump IoT application which persist user information (e.g., credit card).
The M2M and IoT applications that exchange physical or digital assets of users should be reliable and provide risk-free interfaces during transactions. However, the current IoT applications do not hold a consistent structure for the security, access control, and privacy-related models []. This raises serious concerns related to the safety and reliability of transaction processing. Recently, there has been a boom of the latest Information technology Blockchain []. The concept of blockchain is deemed as a decentralization ledger shared among all connected networks. Since it is not feasible to mathematically update the ledger, cryptographic-based methods are employed for the said purpose. The data structure of a blockchain comprises immutable, ordered, and timestamped data blocks. Each block in a design holds a connection with the preceding block, which forms a strict order. In a blockchain, the first block is known as the genesis block used to create the blockchain blocks, also known as block zero. These blocks consist of multiple ordered transactions. Such data structure allows provenance wherein a transaction has a single origin. All users involved in the blockchain network authenticate and approve the transaction. It is a decentralized technology wherein all records are maintained at different locations. This decentralized behavior enables blockchain to govern under multiple entities, indicating that governments or other authorities do not have any access to that. Therefore, the data in the blockchain system could not be altered.
Blockchain has significant properties that directly address the challenges of Intelligent Transportation System (ITS). Therefore, the companies dealing with financial services emphasize on using blockchain because it ensures highly secured transactions of assets []. Furthermore, it provides transparency like public-audibility, an append-only ledger of transactions involved in the chain. The recent emerging of blockchain technology supports the shifting of the traditional payment system at a gasoline pump into a secure automated system []. Smart contracts and Hyperledger Fabric can be employed for allowing a software platform to run without a trusted third party. This behavior leads to opening up opportunities for harnessing product-centric enterprise systems. In this study, a secure payment method is implemented to refuel smart vehicles at smart pumps. The designed model leverages the blockchain platform (i.e., Hyperledger Fabric [,]) to secure the transfer of payment and share information among different gasoline pumps. Firstly, we propose a novel blockchain payment method to fuel smart vehicles in which a user can share sensitive information like credit card credentials or others in a secured, authentic chain of connected networks of the associated franchises of gasoline pumps. This blockchain model is extended towards a web-driven system by designing web front-end technologies like HTML5 and JavaScript for enhancing resource management in a network. Furthermore, we also configure composer-rest-server to expose REST API to visualize services related to the designed system. Afterward, smart contracts’ functionality is embedded to enable data uniformity of card and bank information and other users’ assets and other participants involved in the network. Afterward, an Access Control List (ACL) is defined, which provides access to only valid and authentic users. To enhance the model’s efficiency and performance, we employ DBCouch [] to manage a large number of records and evade form data redundancy problems within the blockchain File System. The performance of the proposed system is evaluated using Hyperledger Caliper [,], a benchmarking tool for blockchain-based system [,].
More precisely, the contributions of this paper are as following:
  • We present PetroBlock: A secure payment mechanism for refueling smart vehicles without human interaction, providing transparency, trust, and privacy.
  • The proposed model can share data among the system’s users while securing sensitive information.
  • We evaluate the designed system using Hyperledger Caliper in terms of transaction latency (average, percentile, minimum and maximum), transaction throughput, resource utilization (e.g., CPU, memory, I.O. ).
The rest of the paper is structured as follows: Section 2 explains the state-of-the-art related work on payment mechanisms for fueling smart vehicles. Section 3 presents the designed methodology, smart contract modeling, implementation, and storage design. Section 4 gives the details of the system results, and Section 5 concludes the paper.

3. PetroBlock Framework

3.1. Scenario of Adversary Model

In our threat model, global external attacker A is considered in opposite to blockchain-based payment platform that performs the following categories of attacks, such as replay attack, impersonation attack, key attack, Sybil attack, false data injection attack, tampering attack, modification attack, man-in-the-middle attack, and hiding blocks attack [].
  • Key attack: This attack exploits the private key leakage vulnerability over a smart car network.
  • Replay attack: An adversary tries to intercepts and then replay a valid data transmission over a smart car network. This attack can be used to deceive financial institutions by duplicating transactions, allowing the adversary to withdraw money directly from their victims’ accounts.
  • Impersonation attack: Under this attack, an adversary tries to masquerade as a legal user for doing some unauthorized transactions in the blockchain.
  • Sybil attack: By frequently interacting in the smart car network, an adversary can form various fake identities using some cars’ reputation.
  • False data injection attack: For making smart cars take wrong control decisions, an adversary injects false data wherein data integrity associated with the control system may get compromised.
  • Tampering attack: Under this attack, an adversary uses the leakage of the private key or 51% vulnerability to tamper with the amounts, transactions, and other information in the ledger.
  • Modification attack: This type of attack consists of modifying the blockchain operation, such as the consensus process.
  • Hiding blocks attack: In this attack, only those transactions are displayed, which he holds a positive image and disguises those that have a negative reputation.
  • Man-in-the-middle attack: Under this attack, an adversary exploits 51% vulnerability, or the private key leakage and identities of two parties are spoofed in the network of a smart car then modify the transmitted data.

3.2. Scenario of Proposed Blockchain Platform

Figure 2 represents the conceptual model of the proposed privacy-preserving blockchain-based payment strategy for fueling smart vehicles in a smart pump. The design platform will manage and update the entire payment mechanism of a smart car’s fueling, storing data related to car users, smart pumps, and a smart car. The PetroBlock data lake serves as an individual property, which is also known as a stored-off blockchain. It is an essential tool employed to conduct assessment analysis like visualization, analytics, and data reporting related to a smart pump and smart car. Furthermore, the pump manager can also access a car user’s data by taking a car user’s permission within the network. In these permissions, access control policies are defined in the smart contract so that integrity and privacy related to user’s data can be maintained. The proposed system comprises nodes that manage the consensus protocol’s execution to maintain the distributed ledger’s consistency. Initially, the smart car user initiates the request of refueling to the smart pump. In response, the smart pump validates the request. On successful validation, the refueling process starts. Once the refueling is completed, the smart car user receives the payment notification. The designed system automatically pays for the refueling once the user grants permission. The successful payment notification is sent to both smart pumps and smart car users.
Figure 2. Conceptual model of the privacy-preserving payment service with smart contract.
Mutual authentication is executed when the car user sends a refueling request to ensure end-to-end secure communication between the car user and the smart pump. Both parties employ the elliptic curve encryption to generate their temporary private and public keys (i.e., keys that are valid for one session), as in []. Then, each party executes the Diffie–Hellman key exchange to compute the shared session key, and hence a session key is established. The session is terminated when they receive a successful payment notification.
Similarly, in Figure 3, the submitting clients reside in the blockchain network to invoke a smart contract and receive a notification on adding a new transaction in the blockchain ledger. The participating networks belong to the business network having permission to submit transactions and maintains assets. The assets can be used in the smart contract to acquired data from sensors. The sensing data are then utilized in various methods for different tasks like paying refueling charges and car maintenance. The newly generated instance of participants and assets are stored in the respective registries. This study considers mapping the identities of participants by employing an enrollment certificate stored by the identity registry. New mappings between identity registries are created when the admin bounds an identity to a participant.
Figure 3. Proposed refueling service interaction scenario.

3.3. PetroBlock System Architecture

The distributed ledger technology of blockchain enables the storage of information while mainlining data privacy and integrity. The system architecture of the proposed PetroBlock is illustrated in Figure 4. The proposed application contains different services like data sharing, smart pump management, secure payment transaction, smart car management, and user identity management. These services mentioned above use smart contracts and distributed ledger as an adapter to the application. The car user and pump manager are responsible for sending the transnational proposal through application to use the proposed blockchain platform’s services like payment of refueling, smart pump management, data sharing, smart car management, and user profile management.
Figure 4. System architecture of proposed blockchain platform.
The proposed system provides a secure way to transfer payments and offers the complete Create, Read, Update, and Delete (CRUD) operation on the involved assets and participants that modified the connected nodes’ data. The user manager is responsible for enrolling the valid participant and providing with enrollment certificate. The consensus manager enables the different participants to connect through the proposed blockchain application. The entity involved in the proposed system is comprised of a distributed ledger and nodes. The node’s responsibility is to endorse transaction proposals through smart contracts and store data. The data consistency is managed by a consensus algorithm, which also ensures the integrity of data. The DLT [] can store the immutable transaction and keep the consistency of every ledger copy by using a different cryptographic algorithm.
Sustaining the copy of a blockchain and transaction processing is the responsibility of nodes in a network. An example of such a blockchain node is shown in Figure 5. The characteristics of the node include blocks, policies, state databases, and smart contracts. The ledger state at a given time is maintained in a state database. The association among block and state databases is represented via sample white box illustration. The policies decide which transaction is recorded to the ledger in terms of node agreement. Each blockchain block contains the data related to payment, user profile, and other entities involved in the blockchain platform. Each block is assigned a sequence number, aiming to identify a block’s order in the blockchain and resist hiding block attack, as in [].
Figure 5. Representation of the node in the proposed blockchain platform.
A smart contract adds functionality to a blockchain because it is a computer program that performs transactions and views the blockchain history and blocks. A distributed database is used to store this computer program. Smart contract features include validations, adding constraints, and applying business logic to the transactions. A blockchain developer may suffer from various challenges while preparing smart contracts. Smart contracts are made using new programming languages such as solidity, making the learning curve steep and hard to maintain. Moreover, the transaction’s execution has minimal performance as nodes in a network follow order during transactions. Furthermore, network concurrency and high parallelism is also attained. We employ Node.js and Java programming languages to implement the smart contract. The presented system has various functions for interaction among users and ledger. For instance, details regarding payment history, fuel storage can be analyzed by the pump manager. A smart car user can record previous refueling visits, payment history, and car consumption. A user holds complete access to CRUD operations and can query the permitted information. The smart contract-based application accepts the transaction, runs different queries on it, and then modifies the ledger state by combining the transaction in a block and giving back the amended result in the form of a response. The illustration about the ledger queries and ledger updates harnessing a smart contract is shown in Figure 6.
Figure 6. Ledger modification using a smart contract.

3.4. PetroBlock Network Structure

Figure 7 presents the network structure of the proposed PetroBlock blockchain network. The main participants are the pump manager and the car user. They can access the secure payment blockchain network with the user application by invoking the exposed REST API’s. The Membership Service Provider (MSP) is used for user authentication, signature generation, credential validation, credential issuance, and verification. The orderer service provides the interface through which peers can connect to the channel and is responsible for transaction orders. The proposed blockchain-based payment mechanism for fueling smart vehicles comprises multiple peer nodes that can endorse the proposal for a transaction or write a block of a transaction to the ledger. Each peer node consists of chaincode, endorsement policies, and storage space.
Figure 7. PetroBlock network structure.

3.5. Workflow for Channel Creation and Setting Chaincode in Proposed Blockchain Network

Figure 8 presents a workflow of channel creation in the proposed PetroBlock platform. The user-like administrator submits a request to the application, which creates a fabric channel to isolate chaincode to the participating member only. This allows the administrator to add the car user and pump manager as a participant to a channel. The channel creation event requests the selected participants through a chain messaging mechanism so that the participating member’s parties can join the channel. The receiving member application accepts the channel message, then invites its peer to join the channel. Once the channel is joined, the application installs the chaincode on the peer file system. This process then allows multiple organization peers to send transactions or query the Chaincode with its state secured in the channel.
Figure 8. Workflow for channel creation and setting chaincode in proposed blockchain network.

4. PetroBlock Implementation

4.1. Development Environment

The designed blockchain platform is developed using Hyperledger Fabric [,], Hyperledger Composer [,], Docker Composer, Docker Engine, and CLI tool. The configuration of the proposed system is shown in Table 1. The blockchain platform is deployed on a Ubuntu platform that involves the Hyperledger Composer, composer-rest-server, and node. We use Ubuntu Linux 18.04 LTS on Intel Core i-5-8500 @3.2 GHz processor with 8-gigabyte memory. Additionally, we use the docker engine for configuring the docker image and container. We also use docker composer for configuring the composer-rest-server. We use Hyperledger Fabric, an open-source platform hosted by the Linux foundation for developing blockchain applications. Moreover, we also use composer-playground to develop and design the business network definition. We use composer-rest-server to create the REST API for the entities involved in the proposed blockchain platform to expose the web services.
Table 1. Development Environment.

4.2. Business Model

The Hyperledger Fabric is divided into three component, i.e., transaction, assets, and participant as shown in Figure 9. In the proposed business model, participants are the c a r u s e r and p u m p M a n a g e r . Assets includes P u m p M o n e y P o o l , P a y m e n t R e c o r d , B i l l s , S m a r t C a r , f u e l , and s m a r t p u m p . Finally transaction are ShareFuelBillwithCarUser, PayFuelBill, UpdateCarRemainingFuel, UpdateFuelPrice, UpdatePumpStorage, UpdateCarVisit, UpdateFuelConsumption, and UpdatePaymentInformation.
Figure 9. Business model of the proposed blockchain platform.

4.3. Smart Contract Modeling

In Hyperledger Composer, we use the composer-rest-server to create the REST APIs services to expose the blockchain platform’s services. In the proposed blockchain platform, we use the following services mentioned in Table 2. These services consist of three parts: resource, verb, and action. The resource is the request path through which we call the services. Verb contains the type of action applied like PUT, POST, GET, DELETE on a particular verb. The action is the service modules of the proposed system.
Table 2. HTTP request in the proposed system.
The transaction is used to interact with the entities involved in blockchain technologies like assets, participants. Table 3 mentions the transactions and events defined in the proposed blockchain-based payment mechanism for fueling smart vehicles. Transactions are defined to provide extra functionality to the user of the system through REST APIs. Events are also part of a transaction and notify the system user if the user application triggers a specific transaction.
Table 3. Transaction and event definition of the proposed blockchain platform.

4.4. Distributed Ledger Storage Structure

This section encompasses details about the structure of the ledger from the presented blockchain platform. The system is split into two parts: (1) blockchain and (2) world state. The current state is another name of the world state in which a ledger state’s present values are kept in a database. The proposed system improves the transaction processing performance as traversing of the transaction log is not required. Apache CouchDB state database supports rich queries for smart contract data modeling in the form of JavaScript Object Notation (JSON). To execute content-based JSON queries in CouchDB, data must be modeled in JSON format. The query methods like getting, delete put in combination with a state key are supported by the format. This allows the invoking of smart contracts by the application by using simple APIs. As shown in Figure 10, one record is stated in the ledger, i.e., record1 of CouchDB having value for a key. A simple state value is supported by the CouchDB having only a complex state value and key-value pair having various other key-value teams.
Figure 10. Distributed ledger storage structure of the proposed blockchain platform.

4.5. Execution Results

This section provides some snapshots to describe the functionality of the proposed system. In Figure 11, the pump management dashboard is illustrated, which contains the pump’s information. The web form allows the user to add a new pump in the system, update pump information, update fuel price, share fuel bill, and pump money pool. The A d d N e w P u m p contains information like PumpID, PumpName, NoOfUnit, FuelCapacity, and ManagerID. The u p d a t e p u m p i n f o r m a t i o n updates the information regarding pump manager and fuel capacity. The P u m p M o n e y P o o l manage the related monetary transaction in the proposed system like total sales of the day, and payment paid by the card for refueling. The proposed pump management dashboard offers the complete CRUD operation related to the pump services, as mentioned in Figure 12.
Figure 11. Pump management dashboard.
Figure 12. Pump management dashboard: update pump record.
The u p d a t e p u m p i n f o r m a t i o n in Figure 12 is used to modify the current pump information via invoking a request to the blockchain platform. The accurate request to the system repopulates the updated information on the user information. The information like pump manager and fuel capacity will be updated from composer-rest-server after a successful response.
Figure 13 shows the dashboard of smart car management contains the web form related to car management. The system allows the portal to add new cars, update car visits for refueling, update fuel consumption, update car remaining fuel, pay fuel bills, and update fuel payments. The A d d C a r feature allows the system to add a new vehicle in the system after a successful transaction. The u p d a t e C a r v i s i t f o r R e f u e l i n g is used to update the time and date of car visit for refueling. The U p d a t e F u e l C o n s u m p t i o n is used to update the smart car’s fuel consumption by updating parameters like No_of_KM_PerLit(Number of km per liter). The U p d a t e C a r R e m a i n i n g f u e l allows the user to update the car fuel after refueling. The user may modify the current information by sending a request to the blockchain. The client interface will repopulate the updated information. P a y F u e l b i l l transaction is used to send fuel bills after refueling. The fuel bill will be calculated by multiplying the price per liter by the number of liters refueled in a car. The U p d a t e F u e l P a y m e n t updates the existing information by sending a request to the proposed blockchain system, and after a successful response, the data are repopulated on the user interface.
Figure 13. Smart car management dashboard.

5. Performance Evaluation

The designed platform is evaluated through Hyperledger Caliper [], which is an open-source benchmark tool available for blockchain platforms. To evaluate the performance of the blockchain-based system, the Linux Foundation has developed Hyperledger Caliper. The designed model’s performance is evaluated for transactions per second, resource utilization, and transaction history. Like transaction latency and transaction throughput, the performance parameters also indicate resource allocation (memory utilization, CPU consumption, I.O., etc.). Table 4 illustrates the environmental setup of Hyperledger Caliper.
Table 4. Environmental setup of Hyperledger Caliper.
The latency and throughput are the two parameters used to analyze the performance of the designed clinical trial service platform. The throughput, also known as transaction per second, is segregated into two sub-groups, such as transaction throughput and read throughput. The transaction throughput is a valid transaction executed during a defined time period, also known as transaction per second (tps), as shown in Equation (1).
Transaction per second = Successful Transaction Time ( Sec )
Furthermore, the tps is measured using all nodes across the entire blockchain. Similarly, the read throughput is calculated as a total count of read operations in a specifically defined time known as read per second (rps) as shown in Equation (2).
Read Per Second = Read Transaction Time ( Sec )
The proposed clinical trial service framework is evaluated in terms of latency, such as read and transaction latency. The read latency is the total round trip time between the send request and receives a response as computed in Equation (3).
Read Latency = Request response time Request time
Similarly, the transaction latency is the total time to authenticate a transaction, including the consensus algorithm’s processing. In the developed system, we also defined the network threshold used to define the time to commit the transaction. This paper has used Practical Byzantine Fault Tolerance (PBFT); therefore, the network threshold is set to a hundred. The mathematical formulation of transaction latency is a calculation using Equation (4).
Transaction Latency = Transaction commit time × network threshold Request time

5.1. Simulation Results

Figure 14 shows information regarding transactions per second (tps) for the proposed blockchain platform. Here tps is deemed like throughput. The proposed model is evaluated by considering different groups. The group is split into three classes, including the number of students as 300, 500, and 1000. The first phase is investigated for the throughput from 300 users. Similarly, 500 users are considered for the second round and 1000 users for the third round. As we have seen the average throughput, the more the number of users, the better the system will perform. As demonstrated in Figure 14, the user-group with 300 users, the average transactions are 30 for the elapsed time of 100ms. However, the value for tps increases by 20 transactions per second if the number of users increases to 500. Finally, with the user-group with 1000 users, the average number of transactions are 56.
Figure 14. Transactions per second.
The latency of executing the proposed system’s invoke transaction having three different sub-classes for minimum and maximum, and average latency is investigated and shown in Figure 15. The categories for user-group are comprised of 300, 500, and 100 users. The average latency for the group of 300 users is reported as 2709 ms. Similarly, the group of 500 users attained an increased value of latency, i.e., 2820 ms. The latency value reaches 2984 for 1000 users. This behavior illustrates that the average latency increases as the number of users increases; however, there is a minor difference between the three groups’ latency values. Furthermore, the group with 300 users has the minimum latency compared to the 500 and 1000 users group. It is observed from the graph that the latency of the group with 1000 users increases linearly until the elapsed time of 29.11.4 ms after the proposed model converges into a stable state.
Figure 15. Latency in invoke transaction.
The latency value, obtained by executing a query function for three different user-groups, is shown in Figure 16. The average latency value for executing query transactions for a group with 300 users is 256. Similarly, the average latency values are 327 and 450 for user groups with 500 and 1000, respectively. We have observed that minimum latency values for 300, 500, and 1000 users are 68, 71, and 97, respectively, and the maximum latency values for 300, 500, and 1000 users are 378, 455, and 850, respectively.
Figure 16. Latency in query transaction.
Hyperledger Caliper is employed to assess the resource utilization of the blockchain network in five iterations. The resource utilization results are expressed in terms of maximum and average memory and central processing unit (CPU) usage rate as illustrated in Table 5. The average CPU utility was captured as 5.77% and memory usage rate at 97.37 MB for the peer. The average CPU utility was captured as 1.25% and memory usage rate at 26.5 MB to the peer for the ordering node. Similarly, the average CPU utility was captured as 0% and memory usage rate at 5.5 MB for CA node. The outcomes of resource utilization reveal that the blockchain network holds a declining rate of resource occupation, increased reliability, and a promising user experience.
Table 5. Resource utilization analysis of the proposed system.

5.2. Security Analysis

We analyze the security of PetroBlock against the following attacks:
  • Key attack: PetroBlock uses elliptic curve encryption to generate the key pair, and the attacker cannot compute the private key as solving the elliptic curve logarithm problem is difficult which ensures the key security. In addition, a different temporary private key is generated for each session agreement between nodes. In this way, the leakage of one private key will not affect: (a) during the session, the attacker cannot compute a session key of an already established session between two nodes, and (b) after the session is terminated, the leaked private key becomes useless.
  • Replay attack: PetroBlock employs a separate temporary private key for each session agreement between nodes. As private keys have bounded lifetime, the replay attack cannot succeed and can be easily detected.
  • Impersonation attack: This attack could only be successful if the attack can obtain the private key. As PetroBlock uses elliptic curve encryption and a separate temporary private key for each session agreement, this attack cannot succeed.
  • Sybil attack: There are various ways to mitigate the effect of Sybil attack on PetroBlock: (a) raise the cost of creating a new identity. This resource requirement limits the number of attackers that attempt to create fake identities, (b) adoption of two-factor authentication mechanism, or (c) collecting the I.P. and MAC addresses of participants, which allows detecting those who have different identities that map to the same address.
  • False data injection attack: In blockchains, consensus algorithms are executed before validating the records. Each node can verify the integrity of the received record when a positive consensus is reached.
  • Tampering attack: Public key cryptosystem is used to encrypt and sign the transactions. This means that a tampering node cannot tamper with the transaction as it does not have the private key of the signer node. In addition, as shown above, PetroBlock is resilient against key attacks, and hence, the private key cannot be exploited by adversaries.
  • Modification attack: As shown above, this attack is not possible as adversaries cannot exploit the private keys.
  • Hiding blocks attack: In PetroBlock, each record has its sequence number. The requested vehicles must provide their records in case others request them. If any node refuses to provide records, it will be isolated, and no one will interact with others.
  • Man-in-the-middle attack: PetroBlock ensures mutual authentication among nodes, as it uses temporary private keys for each session agreement, and hence it can prevent man-in-the-middle attacks.

6. Comparison and Significance

This section encompasses details regarding the comparison of the proposed system with contemporary state-of-the-art studies. To ensure the validity and efficiency of the proposed model, we carried out a benchmark study. The results obtained via evaluation are illustrated in Table 6.
Table 6. Comparative analysis of proposed PetroBlock framework with existing platforms.
Following are characteristics that have been considered to compare the proposed study with existing studies. It can be seen in the table that the study [] holds very identical characteristics to our proposed approach; therefore, we have drawn a comparison of this study with the proposed study. A similar simulation environment to [] is chosen for comparative analysis. During a simulation, a network of 50 peers was selected, and the simulation ran for 60 seconds that executed 960 transactions. The time cost of verifying a new block in the network forms a processing time metric. Figure 17 shows the results of the simulation for the evaluation of processing overhead. It can be seen in the graph that our study has resulted in less overhead than the other approach when a number of blocks varied from 10 to 60. Overall, the proposed study reduced 23% of the processing time.
Figure 17. Processing overhead comparison analysis.
Most of the systems have been formed on a permissionless blockchain network that allows participants to participate anonymously. This indicates that these systems do not have the confidentiality of contracts and transaction data. These systems address this non-confidentiality problem by issuing their own token to fuel smart contract execution. Adverse association with cryptocurrencies can have a major impact on transaction cost and speed. Additionally, it prevents interaction with other distributed systems since then tokens should be unified. On the other hand, our proposed approach is designed on a permissioned network due to which participants are unable to introduce malicious code via smart contract. All participants are aware about each other and all actions are captured in the blockchain as per endorsement policy that was formed for transaction type and network. Moreover, various contemporary systems do not have resource-constrained IoT devices because they have time-consuming mining due to full node deployment on these devices. However, the integration of IoT with blockchain has always suffered from resource-constrained architecture as consensus algorithms are limited to function within these constraints. Some of the existing studies deploy heavy consensus algorithms on the devices that are components of the IoT system, like gateways. However, these IoT gateways have limited storage space. Many existing platforms do not have a facility for lightweight nodes, and full nodes’ deployment must be done on gateways for verification of blocks and transactions. Moreover, this results in making gateways target as they serve as a bridge among the internet and devices. Unlike these systems, our proposed model provides a lightweight solution that mitigates the need to integrate blockchain technology and IoT devices. In addition, it does not require modification of these devices. We have incorporated blockchain as an external entity in order to have secure and reliable storage. Moreover, there is no need to download the entire blockchain network to validate transactions of IoT devices. The proposed system can play an effective role in various IoT scenarios having the limited capability. Additionally, our service APIs are used as a cross-platform to enable communication among blockchain networks and IoT devices. This study also provides the feasibility of integration with other contemporary systems.
This paper has considered a real-life case study for smart space executed during the experimentation phase to evaluate the proposed system’s effectiveness. The proposed system has specifically considered that the model can easily be extended to fulfill other domains like data marketplace, energy trading, and supply chain. For instance, the proposed model may be extended in the food supply chain network as blockchain provides reliable and traceable functionality. IoT sensors can play an effective role hereby being placed on a food item such as fish relegated for transport and remotely sensed data like humidity, temperature, and location. All food processing phases, such as digital compliance information, test results, and audit certificates, may be captured and stored in a blockchain network by enabling access to a shared ledger among all the supply chain parties. The dire need of having an IoT blockchain application with a permissioned network, user-friendly interface, and architecture, no currency exchange, high transactional throughput has been focused on in this study.

7. Conclusions

This paper has presented PetroBlock: A novel blockchain-based payment platform that allows to refuel smart vehicles in a smart pump in a privacy preserved manner. The system has employed Hyperledger Fabric for the said purpose. We have harnessed a smart contract for providing a secure payment transaction for refueling. The model presents a proof-of-concept application using blockchain technology, which maintains a record of all the refueling payments in a decentralized manner. We have employed Hyperledger Fabric, which is permissioned blockchain architecture which provides modular, scalable, and secure foundation for PetroBlock framework. Moreover, we have carried out several experiments in order to evaluate the Petroblock framework performance by using Hyperledger Calliper in terms of resource utilization, latency, and throughput. The result yields that harnessing blockchain technology enhances the performance of the proposed platform. In future, we have aimed to test the interoperability of the designed Petroblock framework with the other IoT-blockchain platform. Moreover, in order to enhance the performance, we are intended to utilize other consensus algorithms for improving the transaction processing rate for fast query execution.

Author Contributions

Data curation, F.J.; Formal analysis, F.J.; Funding acquisition, O.C.; In-vestigation, F.J.; Methodology, H.J.; Software, A.K.; Supervision, A.D.; Validation, M.A.F.; Visualization, F.J.; Writing—original draft, H.J.; Writing—review & editing, O.C., A.K., A.D., M.A.F. and H.J. All authors have read and agreed to the published version of the manuscript.

Funding

Dr. Omar Cheikhrouhou thanks Taif university for its support under the project Taif University Researchers supporting project number (TURSP-2020/55), Taif university, Taif, Saudi Arabia.

Acknowledgments

Omar Cheikhrouhou thanks Taif University for its support under the project Taif University Researchers Supporting Project number (TURSP-2020/55), Taif University, Taif, Saudi Arabia.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Evans, D. The internet of things: How the next evolution of the internet is changing everything. CISCO White Paper 2011, 1, 1–11. [Google Scholar]
  2. Jamil, F.; Iqbal, M.A.; Amin, R.; Kim, D. Adaptive thermal-aware routing protocol for wireless body area network. Electronics 2019, 8, 47. [Google Scholar] [CrossRef]
  3. Hanada, Y.; Hsiao, L.; Levis, P. Smart Contracts for Machine-to-Machine Communication: Possibilities and Limitations. In Proceedings of the 2018 IEEE International Conference on Internet of Things and Intelligence System (IOTAIS), Bali, Indonesia, 1–3 November 2018; IEEE: New York, NY, USA, 2018; pp. 130–136. [Google Scholar]
  4. Jing, Q.; Vasilakos, A.V.; Wan, J.; Lu, J.; Qiu, D. Security of the Internet of Things: Perspectives and challenges. Wirel. Netw. 2014, 20, 2481–2501. [Google Scholar] [CrossRef]
  5. Maroufi, M.; Abdolee, R.; Tazekand, B.M. On the Convergence of Blockchain and Internet of Things (IoT) Technologies. arXiv 2019, arXiv:1904.01936. [Google Scholar]
  6. Nguyen, Q.K. Blockchain—A financial technology for future sustainable development. In Proceedings of the 2016 3rd International Conference on Green Technology and Sustainable Development (GTSD), Kaohsiung, Taiwan, 24–25 November 2016; IEEE: New York, NY, USA, 2016; pp. 51–54. [Google Scholar]
  7. Zhaoyang, D.; Fengji, L.; Liang, G. Blockchain: A secure, decentralized, trusted cyber infrastructure solution for future energy systems. J. Mod. Power Syst. Clean Energy 2018, 6, 958–967. [Google Scholar]
  8. Cachin, C. Architecture of the hyperledger blockchain fabric. In Workshop on Distributed Cryptocurrencies and Consensus Ledgers; IBM: Ruschlikon, Switzerland, 2016; Volume 310. [Google Scholar]
  9. Androulaki, E.; Barger, A.; Bortnikov, V.; Cachin, C.; Christidis, K.; De Caro, A.; Enyeart, D.; Ferris, C.; Laventman, G.; Manevich, Y.; et al. Hyperledger fabric: A distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Porto Portugal April, 2018; ACM: New York, NY, USA, 2018; p. 30. [Google Scholar]
  10. Thakkar, P.; Nathan, S.; Viswanathan, B. Performance benchmarking and optimizing hyperledger fabric blockchain platform. In Proceedings of the 2018 IEEE 26th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS), Milwaukee, WI, USA, 25–28 September 2018; IEEE: New York, NY, USA, 2018; pp. 264–276. [Google Scholar]
  11. Nasir, Q.; Qasse, I.A.; Abu Talib, M.; Nassif, A.B. Performance analysis of hyperledger fabric platforms. Secur. Commun. Netw. 2018, 2018, 3976093. [Google Scholar] [CrossRef]
  12. Baliga, A.; Solanki, N.; Verekar, S.; Pednekar, A.; Kamat, P.; Chatterjee, S. Performance Characterization of Hyperledger Fabric. In Proceedings of the 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), Zug, Switzerland, 20–22 June 2018; IEEE: New York, NY, USA, 2018; pp. 65–74. [Google Scholar]
  13. Sukhwani, H.; Wang, N.; Trivedi, K.S.; Rindos, A. Performance Modeling of Hyperledger Fabric (Permissioned Blockchain Network). In Proceedings of the 2018 IEEE 17th International Symposium on Network Computing and Applications (NCA), Cambridge, MA, USA, 1–3 November 2018; IEEE: New York, NY, USA, 2018; pp. 1–8. [Google Scholar]
  14. Jamil, F.; Hang, L.; Kim, K.; Kim, D. A novel medical blockchain model for drug supply chain integrity management in a smart hospital. Electronics 2019, 8, 505. [Google Scholar] [CrossRef]
  15. Jamil, F.; Iqbal, N.; Ahmad, S.; Kim, D. Peer-to-Peer Energy Trading Mechanism based on Blockchain and Machine Learning for Sustainable Electrical Power Supply in Smart Grid. IEEE Access 2021, 9, 39193–39217. [Google Scholar] [CrossRef]
  16. Jamil, F.; Kahng, H.K.; Kim, S.; Kim, D.H. Towards Secure Fitness Framework Based on IoT-Enabled Blockchain Network Integrated with Machine Learning Algorithms. Sensors 2021, 21, 1640. [Google Scholar] [CrossRef]
  17. Shahbazi, Z.; Byun, Y.C. Towards a secure thermal-energy aware routing protocol in Wireless Body Area Network based on blockchain technology. Sensors 2020, 20, 3604. [Google Scholar] [CrossRef]
  18. Shahbazi, Z.; Byun, Y.C. Integration of Blockchain, IoT and Machine Learning for Multistage Quality Control and Enhancing Security in Smart Manufacturing. Sensors 2021, 21, 1467. [Google Scholar] [CrossRef] [PubMed]
  19. Shahbazi, Z.; Byun, Y.C. Improving Transactional Data System Based on an Edge Computing–Blockchain–Machine Learning Integrated Framework. Processes 2021, 9, 92. [Google Scholar] [CrossRef]
  20. Shahbazi, Z.; Byun, Y.C. A Procedure for Tracing Supply Chains for Perishable Food Based on Blockchain, Machine Learning and Fuzzy Logic. Electronics 2021, 10, 41. [Google Scholar] [CrossRef]
  21. Jamil, F.; Ahmad, S.; Iqbal, N.; Kim, D.H. Towards a remote monitoring of patient vital signs based on IoT-based blockchain integrity management platforms in smart hospitals. Sensors 2020, 20, 2195. [Google Scholar] [CrossRef]
  22. Jamil, F.; Kim, D. Payment Mechanism for Electronic Charging using Blockchain in Smart Vehicle. Korea 2019, 30, 31. [Google Scholar]
  23. Iqbal, N.; Jamil, F.; Ahmad, S.; Kim, D. A Novel Blockchain-Based Integrity and Reliable Veterinary Clinic Information Management System Using Predictive Analytics for Provisioning of Quality Health Services. IEEE Access 2021, 9, 8069–8098. [Google Scholar] [CrossRef]
  24. Knirsch, F.; Unterweger, A.; Engel, D. Privacy-preserving blockchain-based electric vehicle charging with dynamic tariff decisions. Comput. Sci. Res. Dev. 2018, 33, 71–79. [Google Scholar] [CrossRef]
  25. Ginsburgh, I.; Runes, E. Automatic Fueling System for Automobiles. U.S. Patent 3,642,036, 30 April 1972. [Google Scholar]
  26. Jamil, F.; Kim, D.H. Improving Accuracy of the Alpha–Beta Filter Algorithm Using an ANN-Based Learning Mechanism in Indoor Navigation System. Sensors 2019, 19, 3946. [Google Scholar] [CrossRef]
  27. Pustišek, M.; Kos, A.; Sedlar, U. Blockchain based autonomous selection of electric vehicle charging station. In Proceedings of the 2016 international conference on identification, information and knowledge in the Internet of Things (IIKI), Beijing, China, 20–21 October 2016; IEEE: New York, NY, USA, 2016; pp. 217–222. [Google Scholar]
  28. Huckle, S.; Bhattacharya, R.; White, M.; Beloff, N. Internet of things, blockchain and shared economy applications. Procedia Comput. Sci. 2016, 98, 461–466. [Google Scholar] [CrossRef]
  29. Pedrosa, A.R.; Pau, G. ChargeltUp: On blockchain-based technologies for autonomous vehicles. In Proceedings of the 1st Workshop on Cryptocurrencies and Blockchains for Distributed Systems; ACM: New York, NY, USA, 2018; pp. 87–92. [Google Scholar]
  30. Liu, C.; Chai, K.K.; Zhang, X.; Lau, E.T.; Chen, Y. Adaptive blockchain-based electric vehicle participation scheme in smart grid platform. IEEE Access 2018, 6, 25657–25665. [Google Scholar] [CrossRef]
  31. Kim, N.H.; Kang, S.M.; Hong, C.S. Mobile charger billing system using lightweight Blockchain. In Proceedings of the 2017 19th Asia-Pacific Network Operations and Management Symposium (APNOMS), Seoul, Korea, 27–29 September 2017; IEEE: New York, NY, USA, 2017; pp. 374–377. [Google Scholar]
  32. Ferrag, M.A.; Derdour, M.; Mukherjee, M.; Derhab, A.; Maglaras, L.; Janicke, H. Blockchain technologies for the internet of things: Research issues and challenges. IEEE Internet Things J. 2019, 6, 2188–2204. [Google Scholar] [CrossRef]
  33. Huang, X.; Xu, C.; Wang, P.; Liu, H. LNSC: A security model for electric vehicle and charging pile management based on blockchain ecosystem. IEEE Access 2018, 6, 13565–13574. [Google Scholar] [CrossRef]
  34. Kuo, T.T.; Kim, H.E.; Ohno-Machado, L. Blockchain distributed ledger technologies for biomedical and health care applications. J. Am. Med. Informatics Assoc. 2017, 24, 1211–1220. [Google Scholar] [CrossRef] [PubMed]
  35. Otte, P.; de Vos, M.; Pouwelse, J. TrustChain: A Sybil-resistant scalable blockchain. Future Gener. Comput. Syst. 2020, 107, 770–780. [Google Scholar] [CrossRef]
  36. Lin, J.; Shen, Z.; Miao, C. Using blockchain technology to build trust in sharing LoRaWAN IoT. In Proceedings of the 2nd International Conference on Crowd Science and Engineering, Beijing, China, 6–7 July 2017; pp. 38–43. [Google Scholar]
  37. Özyılmaz, K.R.; Yurdakul, A. Work-in-progress: Integrating low-power IoT devices to a blockchain-based infrastructure. In Proceedings of the 2017 International Conference on Embedded Software (EMSOFT), Seoul, Korea, 15–20 October 2017; IEEE: New York, NY, USA, 2017; pp. 1–2. [Google Scholar]
  38. Huh, S.; Cho, S.; Kim, S. Managing IoT devices using blockchain platform. In Proceedings of the 2017 19th international conference on advanced communication technology (ICACT), PyeongChang, Korea, 19–22 February 2017; IEEE: New York, NY, USA, 2017; pp. 464–467. [Google Scholar]
  39. Dorri, A.; Kanhere, S.S.; Jurdak, R. Towards an optimized blockchain for IoT. In Proceedings of the 2017 IEEE/ACM Second International Conference on Internet-of-Things Design and Implementation (IoTDI), Pittsburgh, PA, USA, 18–21 April 2017; IEEE: New York, NY, USA, 2017; pp. 173–178. [Google Scholar]
  40. Ouaddah, A.; Abou Elkalam, A.; Ait Ouahman, A. FairAccess: A new Blockchain-based access control framework for the Internet of Things. Secur. Commun. Netw. 2016, 9, 5943–5964. [Google Scholar] [CrossRef]
  41. Yu, C.; Zhang, L.; Zhao, W.; Zhang, S. A blockchain-based service composition architecture in cloud manufacturing. Int. J. Comput. Integr. Manuf. 2020, 33, 701–715. [Google Scholar] [CrossRef]
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Article Metrics

Citations

Article Access Statistics

Multiple requests from the same IP address are counted as one view.