A secure transaction and smart contract architecture for internet of vehicles

Abstract

Recently, with the popularity of Internet of vehicles (IoV), there is an increasing market demand for integrating blockchain technology and smart contracts in electric vehicles. By utilizing distributed blockchain and smart contract technology, it provides data integrity preservation, traceability, and prevention of forgery. These features can be effectively used in the automated charging system. As a result, IoV can utilize blockchain and smart contract technologies to facilitate seamless payment for charging fees, tolls, parking fees, online shopping and other associated expenses without the need for intermediaries. However, since blockchain and smart contracts operate in an open internet environment, there is a risk of tampering with transaction records. Therefore, enhancing security becomes a crucial concern. The main aim of this study is to emphasize the growing significance of securing transactions and smart contracts in an open transmission environment to prevent potential damage or alteration.

In order to achieve the implementation of secure smart contracts within a resource-constrained IoV, this study investigates various cryptographic mechanisms and realizes the elliptic curve cryptosystem (ECC) is widely recognized for providing strong security with shorter key lengths compared to other public key cryptography methods. This makes it ideal for environments with limited resources. Furthermore, in order to enhance the performance of smart contracts, this study proposes a cloud server architecture for parallel storage of smart contracts to improve access speed. Additionally, we introduce an automated trading framework for smart contracts that operates without human intervention.

Finally, this study uses ECC to ensure the secure transmission of transaction data among the vehicle, base station, and cloud server, as well as to provide mutual verification of identities across all entities involved in the operation. As a result, this study proposes a secure architecture for blockchain and smart contracts that can autonomously initiate transactions while ensuring secure transmission and protection in the IoV.

Introduction

As we are aware, blockchain technology enables secure transactions through decentralization, distributed ledger technology, and artificial intelligence. By leveraging the open and transparent nature of blockchain along with its immutable features, enterprises can effectively manage accounting information while significantly reducing communication costs. Additionally, a smart contract refers to a contractual agreement executed on a blockchain platform that defines transaction terms and is stored in a publicly accessible database. It operates as an automated contract by encoding the agreement's terms into program code. Smart contracts also facilitate the integration of decentralized applications (DApps) onto the blockchain network and handle their conversion into executable program codes. Smart contracts exhibit the following defining features. (1) Autonomy: The smart contract operates autonomously upon initiation without any human intervention, ¹ thereby adhering to the principles of automation and self-execution. (2) Self-contained: Smart contracts possess the capability to independently govern the resources engaged in their computations, encompassing the ability to mediate funds and assets between the parties involved in the contract. (3) Decentralization: Executed autonomously across distributed nodes instead of relying on a centralized server. ² (4) Transparent: Smart contracts are constructed on public blockchains, referred to as public chains, facilitating the transparency of contract content for all stakeholders. (5) Nontampering: Smart contracts operate on the blockchain, where data is securely stored and remains unalterable once deployed. (6) Automatic: The smart contract will be executed automatically, without any manual intervention, once the predetermined conditions are met. (7) Without intermediaries: The absence of a third-party intermediary in the smart contract streamlines operations and reduces costs, while also mitigating the risk of deception by intermediaries. (8) Trust: The parties involved in the smart contract are not required to disclose their identities or assess each other's trustworthiness, as the inherent design ensures that neither party can engage in fraudulent or deceitful activities.

In addition, the main distinction between a typical blockchain and a smart contract lies in their block structure. While the blocks of a blockchain solely store transaction data, a smart contract takes it a step further by accommodating both transaction data and programming code. This distinctive feature empowers the smart contract with storage capabilities and enables the utilization of a specific language for writing programming codes. Once compiled, the smart contract converts these codes into bytecode and securely stores them within its blocks. The smart contract is a code specifically designed for execution on the Ethereum virtual machine (EVM). These contracts are compiled into bytecode using JSON application binary interface (ABI) and await miners to include them in the Ethereum block. Each smart contract serves a distinct purpose, possesses a unique design, and defines its own interface referred to as ABI. Upon deployment of the smart contract, an account is automatically generated, yielding its corresponding address known as the contract account. We interact with the smart contract by utilizing this contract account's address. In summary, a smart contract is an agreement between two parties that utilizes code to define the terms of the agreement and securely stores it on a blockchain, ensuring immutability. The execution of transactions within smart contracts is facilitated by the blockchain itself, eliminating the need for intermediaries and enabling automatic processing. Moreover, these transactions are only triggered when predetermined conditions specified in the agreement are met, thereby establishing a fully decentralized system.

The distinction between conventional and smart contracts

The key distinction between smart contracts and traditional contracts lies in their elimination of the need for intermediaries. Unlike traditional contracts that require third-party involvement for signing and execution, smart contracts only necessitate online signatures from both parties, as illustrated in Figure 1. Once the predetermined conditions are met, the contract's content is automatically executed. Furthermore, these contracts are securely stored in a publicly accessible database, ensuring transparency and immutability. The detailed description is as follows. (1) Traditional contracts: When two parties enter into a partnership agreement, they mutually agree to undertake or refrain from certain actions in exchange for specific considerations. It is imperative that both parties exhibit trust and fulfill their respective obligations. Simultaneously, the involvement of a third-party law enforcement agency becomes crucial, as it assumes the responsibility of adjudicating any breaches of the agreed terms by either party. (2) Smart contracts: The two parties collaborate to digitally sign a contract, which operates as a code on the blockchain, securely stored in a public database and cannot be altered. Multiple parties agree to fulfill or abstain from certain tasks in order to acquire specific items. Trust between them is not necessary as the contract's content is automatically executed and its transparency remains unchanged. Once a smart contract is used, this approach not only eliminates the involvement of third-party companies entirely but also significantly reduces the overall contract duration. ³

Figure 1.

The distinction between traditional contracts and smart contracts.

Benefits of smart contracts

1. Smart contracts do not rely on the involvement of a third-party institution, thus ensuring a high level of openness and transparency. Encrypted transaction records are shared among all participants, guaranteeing that data remains unalterable.

2. Smart contracts can significantly reduce costs by eliminating the need for third-party institutions, while also boasting remarkable attributes such as rapidity, efficiency, and precision. ⁴

3. Smart contracts are designed with each block securely linked to the previous and next records on a specific ledger, providing a high level of resistance to hacking attempts.

The risks of smart contracts

1. When the requirements of smart contracts are not sufficiently stringent, it can lead to developers misunderstanding the requirements, resulting in program execution outcomes that do not align with user expectations. In general, when signing a traditional contract, we seek legal review of its terms beforehand. Similarly, in the future, we may require professional smart contract detection tools to minimize errors by reviewing smart contracts.

2. There are numerous legal issues and challenges to consider in smart contracts, including instances where hackers exploit program loopholes to acquire substantial assets and inflict losses on others. Is there a law in place to restrict their actions? This is also one of the challenges that smart contracts will encounter.

3. Smart contracts enable automated asset transfers on blockchain platforms, particularly involving digital assets represented by cryptocurrencies. It is important to acknowledge that participating in cryptocurrency trading involves inherent risks.

As we know, the Internet of vehicles (IoV) stands for the Internet of vehicles which extends the principles of the Internet of Things (IoT) to vehicles and transportation systems. Internet of vehicles involves connecting vehicles to the internet, allowing them to communicate with each other. This connectivity enables various applications and services aimed at improving efficiency, safety, and convenience in transportation. Although the blockchain-based IoV holds promise for enhancing security, transparency, and decentralization in the transportation sector, there remain numerous challenges and limitations that require attention. These include privacy and security concerns, regulatory compliance issues, energy consumption, and cost implications, as well as complexity factors. Therefore, this study considers the wide applicability and associated conveniences and risks of smart contracts, their future adoption in the IoV environment is highly anticipated. Given the high frequency of transactions in IoV, it becomes imperative to explore alternatives to traditional credit card or contact-based transaction modes by leveraging smart contracts.^5–7 This would enable vehicles to access a more convenient and expeditious trusted transaction mode within smart cities. Therefore, the contribution of this study would like to propose that (1) a wireless communication transmission protocol that ensures the integrity and security of smart contract transactions during their transmission process; (2) a robust security solution with a shorter key length compared to other public key cryptography methods in the IoV environment, which lacks computing resources; (3) a secure architecture for blockchain and smart contracts that can initiate transactions autonomously while ensuring secure transmission and protection in IoV.

The subsequent sections of this document are organized as follows: “Related work” section offers a comprehensive review of research on blockchain and smart contracts, while “A secure transaction and smart contract framework for Internet of vehicles” section outlines the proposed system architecture. Within this section, we introduce a secure transaction and smart contract architecture for IoV, along with details on implementing automated transactions via smart contracts. In “Security and performance analysis of the proposed system” section, this study evaluates the security and performance aspects of our approach. In “Conclusions” section, we ultimately present our conclusions and delineate future research directions.

Related work

With the advancement of blockchain technology, the key features of decentralization, anonymity, immutability, transparency, and consensus have become increasingly important. As a result, many researchers have applied blockchain to the IoT. However, most of these researches lack application in the IoV and rarely discuss how to use elliptic curve cryptography to protect smart contracts. The following are the research topics on smart contracts proposed by scholars in recent years, with a focus on enhancing smart contract security. This study categorizes these studies as follows: (1) research on the application and analysis of blockchain and security for smart contracts, (2) research on security analysis of blockchain in IoT, (3) research on applying smart contracts without a trusted center in automatic transactions on the blockchain, and (4) research on improving the efficiency of smart contracts in blockchain technology. The relevant research proposed by scholars is summarized and compared as follows:

In 2024, Wu et al. developed a secure cross-chain scheme, ⁸ which leverages a relay chain and smart contract for blockchain security. Each blockchain selects proxy nodes to establish a data cross-chain medium using the VRF algorithm. To ensure the secure transmission of cross-chain data, the authors have designed an encryption scheme to protect the smart contract and create mutual constraints between blockchains and relay chains. In this study, however, the reliability of relay chain technology heavily depends on the integrity of proxy nodes. Any failure or attack on a node within the relay chain has the potential to significantly impact the overall blockchain system.

In 2023, Wang proposed a deep learning network scheme for black-boxing, ⁹ which effectually improved the security and privacy of smart contracts. Additionally, the authors developed a lightweight network structure to reduce computational and storage resource consumption. This approach combines one-dimensional CNN and multilayer perceptron to leverage both local and global information from smart contracts, achieving the highest encryption effectiveness. This mechanism mitigates resource demands, improves the robustness of smart contracts, and makes them more practical for widespread use. However, this study does not consider the potential for code vulnerabilities in smart contracts that could result in data leakage, such as unauthorized access or unintentional information disclosure. There may be untested vulnerabilities in the contract that could be exploited by an attacker to gain access to the data stored within the contract.

In 2018, Ali et al. ¹⁰ indicated that the untampered and decentralized nature of blockchain technology provides a feasible solution for addressing security and privacy concerns in the field of the IoT, ¹¹ thereby improving the reliability and robustness of data transmission within this domain. However, some of the research methods and solutions presented in this paper lack experimental validation, so their effectiveness and feasibility in practical applications have not been fully substantiated.

Huang et al. ¹² highlighted that the comprehensive utilization of research findings from this article significantly augments our comprehension of the potential and value of blockchain technology in ensuring data security for IoT devices. Considering multiple systems, this study proposes a robust security mechanism to enhance the reliability and security of IoT devices. However, many IoT devices are constrained by limited computing and storage capabilities, which generate challenges for their participation in the consensus process within a blockchain network. Some of the proposed solutions outlined in the document may not be feasible for implementation on resource-constrained devices.

In 2018, Kshetri et al. ¹³ introduced a security framework for IoT based on blockchain technology, which leverages blockchain to verify device identity, authenticate its legitimacy, securely store initial information, and ensure the integrity of data. Furthermore, Bera et al. ¹⁴ introduced a blockchain-powered architecture for data storage and access control in the field of IoT to enhance data security. These studies indicate the significant applicability of blockchain technology in safeguarding the data integrity of IoT devices. However, these studies do not examine the resilience of the proposed DBACP-IoTSG against emerging attack methods such as Sybil attacks, DDoS, and eclipse attacks.

In 2016, Christidis et al. ¹⁵ explored the possibility of enabling mutual verification among untrusted participants in a blockchain network, removing the requirement for a centralized trust center. This study elucidates the operational mechanics of this mechanism and investigates the utilization of smart contracts residing on the blockchain to facilitate multistep process automation. However, some research methods and solutions in this paper lack experimental validation, thus not fully demonstrating their efficacy and feasibility in practical applications.

In 2018, Antonopoulos and Wood ¹⁶ investigated the potential for enhancing blockchain technology through the integration of smart contracts and consensus mechanisms. They examined the use of protocols and user interfaces in smart contracts to facilitate all stages of contract execution, enabling users to incorporate personalized programming logic within the blockchain architecture. Additionally, the authors conducted a comprehensive analysis of blockchain technology, highlighting the crucial role of cryptography in ensuring data integrity, privacy, and security across various applications. Furthermore, this study delved into the development and implementation of decentralized applications (Dapps) built on blockchain technology with attributes such as decentralization, security, and transparency.

In terms of the application of blockchain technology, Christidis and Devetsikiotis ¹⁵ delved into the field of IoT. Androulaki et al. ¹⁷ shed light on supply chain management, emphasizing the heightened significance of encryption. These studies underscore the paramount importance placed on data security and privacy. Cryptography assumes a pivotal role in ensuring data protection and trustworthiness, thus playing a crucial function.

In 2016, Narayanan et al. ¹⁸ conducted an analysis of the cryptographic mechanism employed in blockchain technology, emphasizing its crucial role in ensuring transaction security and maintaining the integrity of the blockchain. These studies offer valuable insights into both operational and secure aspects of blockchain technology, underscoring the imperative for robust cryptographic mechanisms. This study simultaneously investigated the security concerns associated with bitcoin, including double-spending attacks, 51% attacks, and other potential security risks.

However, the aforementioned studies primarily utilize blockchain technology to address transactional issues. Nevertheless, it is worth noting that blockchain lacks customization capabilities and fails to automatically trigger tasks based on consumer demand. Furthermore, these studies ignore the information security transmission architecture of blockchain. Therefore, this study would like to propose a blockchain architecture capable of autonomously initiating transactions while ensuring secure transmission and protection in order to fulfill the demands of the IoV. Simultaneously, our proposed scheme seamlessly integrates smart contract technology and the elliptic curve cryptosystem (ECC) into our system to effectively tackle challenges associated with data sharing, payment systems, and privacy within the realm of vehicles. This robust implementation guarantees the utmost security for the IoV.

A secure transaction and smart contract framework for IoV

The system initialization

To enhance the security of transaction data and smart contracts between the IoV and the store, this study employs elliptic curve cryptography for mutual authentication. We suggest utilizing the base station as an edge server to reduce the computational load on the cloud server. The vehicle establishes a direct connection with a base station for data transfer. Upon receiving the data, the base station transmits the data to the cloud server, enabling the proposed system to effectively distribute and reduce communication load while enhancing IoV performance, as illustrated in Figure 2. To complete the entire system, this study must carry out system initialization involving phases P1–P3. The purpose of P1 is to register participating vehicles and base stations, P2 involves mutual authentication, and P3 facilitates secure data transmission, as depicted in Figure 3.

Figure 2.

The proposed architecture of the Internet of vehicles in this system.

Figure 3.

The complete system initialization process involves phases P1–P3 and steps S1–S4.

In the first phase, participants are required to complete registration in phase P1. This is imperative to authenticate the identities of participating vehicles, base stations, and cloud servers using elliptic curve digital signature algorithm (ECDSA) digital signature. This signature verification process is elaborated in steps S1–S4 of phase P2 as outlined below. Subsequently, participants can perform the security of data transmission during phase P3. The entire initial procedure is depicted in Figure 3.

S1: Choose an elliptic curve EGF(p) (e, f) and a generator R. The order of the elliptic curve is denoted as n = |EGF(p) (e, f)| + 1, representing the total number of points on the curve including those at infinity.

S2. Choose a point R = (X_R, Y_R) and a private key s, where s∈[1, n − 1], with the order of R denoted as n. Subsequently, this system employs the generator R to compute Pk = s × R = s × (X_R, Y_R) and obtain the public key represented as (e, f, p, n, R, Pk).

S3. Choose a randomly generated integer t∈[1, n − 1], and compute the point G = (X_G, Y_G) = t × R = t × (X_R, Y_R). Subsequently, employ the coordinate values (x, y) along with the primitive message M derived from point G as parameters. Utilize SHA256 as the hash function to calculate f = HASH(M), w = X_G mod n, and r = (s × w + f) × t⁻¹ (mod n). The resulting signature is denoted as (M, w, r). In case either w or r equals 0 during this process, it is necessary to repeat steps S1 through S3 by selecting a new random integer for w until completion.

S4. The receiver obtains the message M along with the signature value (M, w, r). Subsequently, f is computed as HASH(M), followed by calculating z as the modular inverse of r modulo n. Then, v₁ is obtained as f multiplied by z modulo n, and v₂ is obtained as w multiplied by z modulo n. D = (X_D, Y_D) = v₁ multiplied by R plus v₂ multiplied by Pk. Verification of the equation w = X_D follows. If this equation holds true, then the signature is accepted; otherwise, it is rejected.

When the system has verified the participant's identity, then the vehicle can launch a transaction with the store. Initially, the vehicle generates and signs the transaction data before deploying it to the blockchain. Upon receiving this transmitted message from the vehicle, the base station must first validate its signature and subsequently broadcast it to the EVMs. Similarly, upon receiving a message from the base station, the EVM also has to verify whether the base station's signature is accurate prior to executing any smart contract.^19,20 Simultaneously, data transmitted by the base station is disseminated to other EVMs. Ultimately, this transaction will be recorded across all EVMs on the blockchain as depicted in Figure 4.

Figure 4.

The system initiates transactions, signs, and verifies signatures to broadcast Ethereum virtual machine (EVMx), deploying them to the blockchain. Finally, the transaction is stored in the blockchain.

The proposed secure transaction mechanism

After the above entire system initialization, the system is ready to enter the secure transaction and smart contract process. Here, we propose a secure transaction mechanism to protect the entire transaction data and the smart contract. The detailed process includes the following phases.

Secure phase

In this study, the base station was deployed at the network periphery as the edge server to alleviate the computational load of the cloud server and enhance system efficiency by providing intermediary computing services between vehicles and cloud servers. To ensure the secure transmission process of signatures and data, an elliptic curve cryptography system is employed by both the vehicle and the base station. At the beginning, the vehicle randomly selects a private key K_A and then proceeds to calculate the corresponding public key. Z_A = K_AP, where P represents a prime. Simultaneously, the base station chooses a private key K_B and calculates its respective public key Z_B = K_BP. Subsequently, Z_A is transmitted from the vehicle to the base station, while Z_B is sent from the base station to the vehicle. Subsequently, in order to validate the participants’ identities, this study employs the ECDSA digital signature for mutual authentication between the vehicle and the base station.

The system carefully selects an elliptic curve and a key pair (dA, Qa), where dA represents the private key as a randomly generated integer within the range of [1, n − 1], with n denoting the total count of points on the elliptic curve, encompassing those at infinity. Additionally, the public key is determined as Qa = dA × G, where G serves as a distinguished generator of the chosen elliptic curve. The detailed procedure is as follows.

The vehicle chooses a key pair (K_A, Z_A), where P is a prime number and Z_A= K_AP.

The base station chooses a key pair (K_B, Z_B), where P is a prime number and Z_B= K_BP.

The vehicle transmits Z_A= K_AP to the base station.

The base station transmits Z_B= K_BP to the vehicle.

The vehicle receives Z_B= K_BP and computes the shared session key K_AZ_B= K_AK_BP, while the base station also derives the shared session key K_BZ_A= K_BK_AP, where K_AK_BP = K_BK_AP.

Afterward, the vehicle and the base station utilize ECDSA for conducting the mutual authentication phase.

Signature phase

The vehicle randomly selects an ephemeral key, denoted as k, from the range [1, n − 1], and proceeds to calculate P = k × G using multiplication. The X coordinate of point P is represented by R. In the event that R equals 0, the vehicle will reselect a new value for k. Subsequently, the vehicle determines the hash value of the transmitted data M as SHA256(M) = z and performs further computations accordingly:

$$S=k^{-1}(z+dA\times R)modp$$ (1)

In the context of a finite field GF (p), where p is a prime number, if S equals 0, the vehicle will then reselect the newer k. Consequently, (M, R, S) represents the resulting signature in this scenario.

Verification phase

After receiving the signature data, the base station proceeds to verify the accuracy of the signature by evaluating the equation provided:

$$P=S^{-1}\times z\times G+S^{-1}\times R\times Qa$$ (2)

Since Qa = dA × G, this study consequently deduces the subsequent procedures:

$$P=S^{-1}\times z\times G+S^{-1}\times R\times (dA\times G)=S^{-1}(z+dA\times R)\times G.$$ (3)

Additionally,

$$P=k\times G=S^{-1}(z+dA\times R)\times G.$$ (4)

Therefore,

$$k=S^{-1}(z+dA\times R).$$ (5)

As a consequence, equation (1) can be derived as S = k⁻¹(z + dA × R).

Similarly, the verification of identification is employed by both the base station and the cloud server in accordance with this scheme. Then, this study introduces the elliptic curve Diffie–Hellman (ECDH) and ECDSA to enhance the security of both the transaction record and the smart contract. The detailed phases of the proposed secure transaction and smart contract process are outlined below and depicted in Figure 5. Furthermore, Table 1 presents a thorough overview of the notations used in this study.

Figure 5.

The specific phases of the secure transaction and smart contract process being proposed.

Table 1.

Notations and their respective explanations.

Notations	Explanations
EGF(p)(e, f)	In a prime field of an elliptic curve, (e, f) represents a generator point.
R	A generator in the elliptic curve cryptosystem.
Hash(M)	Message M is hashed.
KX	The private key utilized by device X in the elliptic curve Diffie–Hellman protocol.
ZX	The public key utilized by device X in the elliptic curve Diffie–Hellman protocol.
(KX, ZX)	The key pair associated with device X.
S	The session key established between two parties.
SignX(KX, MX)	The message MX is signed by device X using the private key KX through ECDSA.
Es[MX||SignX(KX, MX)]	Encrypt the transmitted data and the signature outcome utilizing the session key derived from ECDH.
Verify(ZX, MX, Sign X (KX, MX))	Verify the signature outcome of message MX utilizing public key ZX.
TX	A record of the transaction conducted by device X.
SC x	A smart contract conducted by device X that operates on blockchain technology.
T X |SC x	The merge of TX and SCx.
Sign X (KX,TX|SCX)	The ECDSA signature result of (TX|SCx) utilizing the private key KX.

Phase 1: Obtain the session key

In order to guarantee the security of data transmission, both the vehicle and the base station initiate an ECDH process to derive a session key S. Similarly, the base station establishes another ECDH process with the cloud server to obtain a shared session key.

Phase 2: ID verification

In order to verify the identity of the participants, the vehicle initiates a message M_A and applies ECDSA to sign it, resulting in the signature Sign_A(K_A, M_A). Subsequently, both parties employ the session key S to encrypt both the message and its corresponding signature as E_S[M_A||Sign_A(K_A, M_A)]. These encrypted outcomes are then transmitted to the base station (BS). Similarly, base stations and the cloud server execute analogous procedures and obtain the result as E_S[M_B||Sign_B(K_B, M_B)].

Phase 3: Verify signature

After receiving the encrypted data transmitted by the vehicle, the base station promptly decrypts the received data using the mutually shared session key S and obtains [M_A||Sign_A(K_A, M_A)]. Subsequently, the base station verifies the digital signature through a validation process employing the vehicle A's public key Z_A as verify (Z_A, M_A, Sign_A(K_A, M_A)). Similarly, when vehicle A receives encrypted data from the base station, vehicle A expeditiously decrypts it utilizing their shared session key S to obtain [M_B||Sign_B(K_B, M_B)]. The vehicle A then proceeds to validate the digital signature using base station's public key Z_B as verify (Z_B, M_B, Sign_B(K_B, M_B)). In a similar manner of operation between them, both are assumed for confirming each other's signatures by means of this approach.

Phase 4: Send transaction record

When a transaction T_A is generated between the vehicle and the store, the vehicle initially combines T_A with smart contract SC_A as [T_A|SC_A]. Subsequently, using private key K_A, the vehicle signs [T_A|SC_A] to obtain Sign_A(K_A, T_A|SC_A). The secured transaction and signature are then encrypted using session key S of both parties as E_S[T_A|SC_A||Sign_A(K_A,T_A|SC_A)]. Following this encryption process, the vehicle transmits the encrypted result to the base station. Upon reception of the encrypted data, the base station proceeds to decrypt it using session key S and subsequently employs public key Z_A of the vehicle to verify if verify(Z_A, T_A|SC_A, Sign_A(K_A,T_A|SC_A)) confirms that original data is accurate. The base station then encrypts the transaction data using the session key S to secure the transmitted data as E_S(T_A|SC_A||Sign_A(K_A,T_A|SC_A)), and then delivers the encrypted result to the cloud server. Upon receiving the transmitted data, the cloud server decrypts the encrypted data using the session key S of both parties and then verifies the signature result as verify(Z_A, T_A|SC_A, Sign_A(K_A,T_A|SC_A)). If the signature result is correct, then the cloud server sends E_S(T_A|SC_A||Sign_A(K_A,T_A|SC_A)) back to the base station.

The base station proceeds to encrypt the transaction data using the session key S in order to ensure the security of the transmitted information, resulting in E_S(T_A|SC_A||Sign_A(K_A,T_A|SC_A)). Subsequently, this encrypted outcome is conveyed to the cloud server. Upon receiving the transmitted data, the cloud server decrypts it employing both parties’ session key S and subsequently verifies the signature result as verify(Z_A, T_A|SC_A, Sign_A(K_A,T_A|SC_A)). If this verification process yields a correct signature result, then E_S(T_A|SC_A||Sign_A(K_A,T_A|SC_A)) is returned back to the base station by the cloud server.

Phase 5: Write smart contract into blockchain and store into server

Upon receipt of the data transmitted from the cloud server, the base station undergoes decryption and verification of the digital signature for correctness. Subsequently, it publishes and records the [T_A|SC_A] into the blockchain while simultaneously notifying the cloud server to store [T_A|SC_A] in its storage system. This facilitates expedite access and retrieval of transactions and contracts, thereby enhancing their utilization and query capabilities.

The proposed secure internal blockchain transactions and smart contract mechanisms

Initially, the system is provided with a keystring of arbitrary length. Upon execution of the Generatekeys(keystring) function, two keys are generated: a public key Pk and a private key Sk. Signatures can be obtained by computing Sign(Sk, message) using the private key and messages. This signature comprises encrypted strings derived from both the secret key and message; different messages output distinct signatures. To verify whether a given message and signature are legitimate, the receiver inputs parameters including public key Pk, message, and signature into the Verify(Pk, message, signature) function for verification purposes. Furthermore, Table 2 presents a thorough overview of the notations used in this study.

Table 2.

Notations and their respective explanations.

Notation	Explanations
Vehicle	A vehicle within the Internet of vehicles (IoV).
Base station	The edge computing server.
Sk	The private key utilized by the device employing the ECDSA.
Pk	The public key utilized by the device employing the ECDSA.
(Sk, Pk)	The key pair associated with the vehicle.
Sign(Sk, message)	Sign the message utilizing the private key Sk.
Verify(Pk, message, Signature)	Verify the signature outcome of the message utilizing the public key Pk.
T Vehicle	A transaction record of the vehicle.
SC	Smart contract.
TVehicle|SC	The merge of TVehicle and SC.
SignVehicle(TVehicle|SC)	The signature outcome of (TVehicle|SC) utilizing the ECDSA.
Block ID	The number of the block in the blockchain.
Previous hash	The cryptographic hash value of the previous block.
Hash	The cryptographic hash value of the present block.
Nonce	The bookkeeper may input a variable to ensure that the resulting Hash value satisfies a specific condition.

When we create an account, we must first enter a keystring of any length. After the vehicle passes through the Generatekeys(keystring) function, it will produce a private key Sk and a public key Pk to form a key pair (Sk, Pk). At this point, the public key serves as the designated address for the account. When initiating a transaction, the vehicle must employ its private key in conjunction with relevant transaction information to compute the signature result using Sign(Sk, message). For the purpose of simplification, this study represents the conjunct result as [T_Vehicle|SC||Sign_Vehicle(T_Vehicle|SC)], where the Sign_Vehicle(T_Vehicle|SC) is equal to k⁻¹(HMAC(T_Vehicle|SC) + Sk× R) mod p. The detailed secure process of internal blockchain transactions and smart contracts is depicted in Figure 6. To verify if the transaction was initiated by the vehicle, the blockchain must utilize the address (also known as the public key), signature, and transaction with a smart contract of the outgoing account, utilizing Pk to execute the verification function Verify(Pk, message, [T_Vehicle|SC||Sign_Vehicle(T_Vehicle|SC)]) before recording it into the ledger on blockchain.

Figure 6.

The secure execution of internal blockchain transactions and smart contracts.

If a third party attempts to forge a transaction from the vehicle to the base station, they would be unable to replicate the vehicle's signature due to their lack of access to its private key. Even if this third party uses their own private key for signing, verification would detect and reject it. Digital signatures ensure that transactions can only be initiated through authorized accounts.

In addition to ensuring that each individual can only send transactions to their own account, the digital signature employs public keys as addresses, thereby giving an anonymous characteristic to the blockchain.^21–23 Within this system, users have access to every transaction recorded in the ledger; however, they are unable to confirm the actual holders of those accounts. It becomes challenging to track ownership as individuals can create multiple accounts.^24,25 With the inclusion of the digital signature, Figure 7 illustrates that the content format of the ledger, and Figure 8 is the usage of notations in this system.

Figure 7.

The detailed blockchain architecture includes smart contracts.

Figure 8.

The internal smart contract consists of application binary interface (ABI) and bytecode.

When developers write the smart contract code, they obtain two outputs after compilation: the compiled bytecode and the ABI file in JSON format. During the implementation of our smart contract on the blockchain, we utilize the newly created ABI as a framework by encapsulating it with bytecode within data,^26–28 subsequently submitting it to the blockchain network for miners to incorporate into a block as depicted in Figure 8. Upon successful deployment, an account is automatically generated and its corresponding address is returned, commonly referred to as the contract account. Interactions with the smart contract are facilitated through this specific address.

The implementation of secure and automated transactions via smart contracts

In this study, we employ the proposed mechanism for information security transmission to protect the transaction and contract data, and we also propose the automatic transaction framework within the IoV as shown in Figure 9. The proposed mechanism can replace many insecure and physical transaction modes at this stage. Here, we assume that the vehicle passes through a gas station. The vehicle can directly consume according to the proposed mechanism with smart contacts to securely consume and deduct. Similarly, this study also can modify some processes to be applied in certain scenarios, such as toll booths or parking lots.

Figure 9.

The proposed system's implementation facilitates secure and automated transactions with the store through smart contracts.

Initially, the vehicle has its own EWallet, and there is a locked storage area in this system which is governed by the smart contract. The following is the proposed detailed process using the smart contract.

Stage 1. The store utilizes the company's account to register the information of sold merchandise in the smart contract.

Stage 2. Stores store their sold merchandise and a key K_s in a secured storage area under the control of the smart contract.

Stage 3. The vehicle makes a payment at the store and transfers an adequate amount of funds from the vehicle to store to the smart contract's account as [T_Vehicle|SC||Sign _{PK v}(T_Vehicle|SC)].

Stage 4. The smart contract validates the presence of the merchandise and ensures that the vehicle has transferred sufficient funds to the smart contract's account.

Stage 5. If the specified criteria are satisfied, the smart contract will initiate a transfer of funds to the store's account and authorize the vehicle's private key PK_v to unlock the storage area.

Stage 6. The vehicle utilizes its private key PK_v to access the storage area, and then acquires K_s to initiate consumption.

The aforementioned transaction procedures can be executed automatically without human intervention. Additionally, our proposed information security transmission and protection mechanism of ECDH and ECDSA can effectively prevent malicious modifications, ensuring the utmost security of the transaction.

Security and performance analysis of the proposed system

Security evaluation

To ensure the security of the proposed mechanism, we employ multiple vulnerability detection tools and assess the robustness of the utilized ECDSA digital signatures. Additionally, we conduct a comparative analysis of relevant studies conducted by various scholars in this field.

Security vulnerability detection tools and working environment

At this stage, in order to avoid the smart contract from being subjected to common attacks, including 51% attacks, private key custody, double spending issues, information leakage, etc. Numerous source code detection tools have been proposed and implemented, including MythX, Scribble, Mythril, Manticore, Echidna, Slither, Vandal, Zeus, among others. However, these tools primarily serve the purpose of comparing the vulnerability code gathered in the current database to ascertain its consistency with the database content. Nonetheless, they possess limitations when it comes to security vulnerability detection, particularly for vehicles, base stations, and cloud computing servers involved in IoV where identity authentication is absent. Therefore, we suggest and exploit the following stages of security vulnerability detection tools to detect the contract before the contract is deployed:

Phase 1. Automated security analysis: Firstly, the system utilizes MythX to conduct comprehensive static analysis, dynamic analysis, and symbolic execution of smart contracts. It effectively identifies known vulnerabilities, traces their source code execution, and generates a meticulous report encompassing a summary of all identified issues.

Phase 2. Insert code annotation test: Subsequently, we utilize Scribble, a runtime verification tool, to develop a specification language for smart contract properties. This tool converts Scribble properties into concrete Solidity assertions and employs inserted Solidity assertions to validate development specifications and identify potential vulnerabilities.

Phase 3. Fuzzing test: Users can input their initial Scribble property, and then automatically or semiautomatically generate scrambled data into a program, while also monitoring the contract for any anomalies.

Phase 4. Spot check: If you use Solidity, you can use the Ethereum foundation's developer advice checklist to check the content of the contract one by one, with the goal of identifying any inconsistencies in the overall design and security vulnerabilities.

Phase 5. Third-party security auditing: Through an in-depth code review conducted by the smart contract security audit team, they will manually scrutinize the code to identify vulnerabilities. Manual code review prevents potentially catastrophic vulnerabilities after launch.

Phase 6. Deployment of contracts: After the above security checks, the contract is deployed to the blockchain.

By conducting source code detection as mentioned above, we can ascertain the precision of smart contracts to prevent occurrences of errors such as double spending. Furthermore, in addition to authenticating identity, the proposed security transmission mechanism also incorporates encryption and sealing of transaction data and smart contracts. This not only compensates for the limitations of these tools but also enhances the overall security of the IoV.^29,30

In addition, common eclipse and DDoS attacks are categorized as network layer attacks. The eclipse attacker initiates a large number N of node IDs, exceeding the maximum allowed TCP connections for an Ethereum node (preset at 25). Upon restart of the victim node, incoming connections from the N nodes overwhelm its TCP connections, completing the eclipse attack.^31,32 The absence of limits on incoming connections for Ethereum nodes is a significant vulnerability, prompting this study to recommend imposing restrictions to ensure that outgoing connections can still be made. Furthermore, in geth version 1.8.0, it is possible to limit the number of incoming connections with a default upper limit set at max peers equal to 3. Therefore, this study utilizes geth version 1.8.0 to restrict max peers and mitigate against eclipse attacks.

In addition, to mitigate DDoS attacks, this study restricts requests to prevent excessive requests from a single source.^33,34 Additionally, access control lists can be implemented to limit access to suspicious IP addresses. Furthermore, as sybil attacks manipulate the Internet by generating numerous false identities,^35,36 it is crucial for the security of the blockchain network that a large amount of nodes are genuine and not malicious. This study also optimizes and adopts enhanced consensus mechanisms such as proof-of-work and proof-of-stake to increase attack costs and resist sybil attacks. ³⁷ As a result, this study effectively mitigates network layer attacks and consensus layer attacks.

The robustness of the utilized ECDSA digital signatures

In this study, the device is required to input a string of any length during account creation. Subsequently, Generatekeys() function generates both public and private keys. In this scenario, the public key serves as the account address. When initiating a transaction, the initiator must append the signature obtained through Sign() function using their private key along with the transaction. The verification process involves checking whether the transaction was initiated by matching the outgoing account's address named public key, signature, and content of the transaction. Consequently, despite attempting to initiate a transaction from the vehicle to the base station, counterfeiters fail due to their lack of knowledge regarding the vehicle's private key and inability to replicate its signature.

Additionally, in recent years, scholars have put forward that the majority of studies on smart contracts primarily focus on code vulnerability detection, intrusion detection, contract platform, and system architecture. However, there is limited discussion regarding the utilization of cryptographic systems to enhance information security transmission. Furthermore, the utilization of smart contracts in the realm of IoT is predominantly favored by scholars, with limited research conducted in comparison to the domain of IoV. This highlights our research contribution.

Here, we will compare the smart contract mechanisms proposed by several esteemed scholars with our proposed scheme on supporting IoV, encryption systems, and digital signatures. Our proposed scheme utilizes ECC and ECDSA to assure participant identity and enhance system security. In contrast, other approaches predominantly rely on traditional blockchain architecture, which owns authentication-related security concerns as outlined in Table 3.

Table 3.

The comparison of the relevant research.

Authors	Research topic	Support IoT blockchain	Support IoV smart contracts	Identity verification	The ECC encryption algorithm and ECDSA digital signature scheme
This proposed scheme	A secure transaction and smart contract architecture	V	V	V	V
Christidis et al. 15	Blockchains and smart contracts in IoT	V	X	X	X
Mosenia et al. 38	IoT reference models	V	X	V	X
Das et al. 39	Security protocols in IoT	V	X	V	X
Jayapal et al. 40	IoT solutions to attacks	X	X	V	X
Hassija et al. 41	Applications of IoT security	V	X	V	X
Vangala et al. 42	Certificate-based authentication for vehicle accident detection	V	V	V	X
Rahman et al. 43	A blockchain-based secure Internet of vehicles management framework	V	V	V	X
Bera et al. 4	Blockchain-based access control protocol in IoT	V	X	V	X
Wu et al. 8	A secure cross-chain mechanism based on relay chain and smart contract encryption scheme	X	X	X	X
Wang 9	Securing and lightweighting smart contracts based on multiple network structures	X	X	X	X

Efficiency and performance assessment

This study aims to compare and evaluate the time required for deploying transaction data and smart contracts onto the blockchain,^37–39 taking into consideration the encryption, decryption, and digital signature processes utilizing elliptic curve cryptography techniques such as ECDH and ECDSA. The experimental environment utilizes a highly integrated ARM Cortex-M4 192 MHz single core CPU with a 1T1R antenna and a 2.4 GHz Wi-Fi/BT (b/g/n) embedded module for the IoV on-board units and as the base station for simulation calculations.

In addition, we employ the VMware to simulate EVMs and cloud servers.^44,45 The time consumed by the vehicle and base station for ECDH and ECDSA operations is negligible. ⁴⁶ At the outset, Figure 10 illustrates that the system is required to store smart contracts to all EVMs, resulting in a time-consuming process. Once all EVMs are stored, subsequent transactions only need to write a portion of the EVM, leading to a steady increase in consumption time. Additionally, this system concurrently stores the smart contracts in both EVMs and the cloud server. Figure 11 demonstrates that the necessary time grows exponentially with an increasing number of EVMs in the network. As the number of EVMs increases, deploying contracts to the peer-to-peer network and executing miner operations become time-consuming due to contract deployment on each EVMS, resulting in significantly increased consumption time. However, as contracts are written to the cloud server, transaction times become more consistent and subsequently speed up contract access times while improving performance by up to 81%. Additionally, in this proposed system, the contracts are deployed on both the EVM and the cloud server to enhance contract accessibility. Consequently, certified vehicles can directly access and execute these contracts through the cloud server, thereby expediting contract execution. Figure 11 illustrates a comparison between the execution speed of contracts accessed via the EVM and those accessed through the cloud server. Since executing through the cloud server only requires a single access, it is more efficient compared to EVM which needs to be searched, accessed, and executed through the peer-to-peer network, resulting in significant consumption of running time without the cloud server.

Figure 10.

The time needed for elliptic curve Diffie–Hellman (ECDH) and elliptic curve digital signature algorithm (ECDSA) scheme steadily increases following the storage of smart contracts in all Ethereum virtual machine (EVMs).

Figure 11.

The proposed system utilizes a cloud server to enhance the efficiency of accessing smart contracts.

We also evaluate the time taken to execute smart contracts using ECC cryptosystems. The time taken for each of the 40 transactions is assessed. As shown in Figure 12, the majority of the transaction time is attributed to writing smart contracts following ECC operations. Importantly, the transaction time demonstrates a consistent increase with higher trading volume. Furthermore, this study compares our proposed smart contracts with ECC cryptosystems to a secure cross-chain scheme. ⁸ The simulation results suggest that our proposed scheme demonstrates superior performance in transaction time compared to the secure cross-chain scheme, given equivalent transaction volumes.

Figure 12.

The time consumption comparison among various schemes.

This study also evaluates the transaction throughput by comparing the smart contract operation with and without ECC cryptosystem to assess its impact. As depicted in Figure 13, it illustrates that while the integration of ECC cryptosystem into smart contracts requires additional time for obtaining the conference key and verifying the ID and signature before the transaction stage, it has a limited effect on the number of smart contracts processed within a fixed time frame. Furthermore, our scheme is compared with the secure cross-chain scheme in this study. Figure 13 demonstrates that our scheme surpasses the secure cross-chain scheme in terms of throughput efficiency under the same time constraint. Over time, our scheme continues to exhibit a steady increase in throughput, whereas cross-chain remains constant.

Figure 13.

The comparison of transaction throughput across various schemes.

To achieve resource utilization, we evaluate the consumption required for implementing the proposed mechanism, including CPU, memory, and storage. The experimental results demonstrate that the resource consumption percentage for an ECC cryptosystem increases with transaction volume but remains within an acceptable burden range without overloading the system. Despite integrating security functions, the results can be observed from the resource utilization scale depicted in Figure 14, as disclosed by the operating system. This study refines the scale of resource utilization into increments of 0.1 for clarity. For example, when the number of transactions reaches 20, we can observe the utilization percentage of various resources. It has been noted that integrating ECC mechanism into smart contracts leads to an approximate 10% (the findings indicate that ((3.19−2.9)/2.9)) increase in CPU consumption compared to smart contracts without ECC, about 0.69% ((2.92−2.9)/2.9) in memory, and about 3.4% ((3−2.9)/2.9) in storage.

Figure 14.

The resource consumption percentage for an elliptic curve cryptosystem (ECC) cryptosystem increases as transaction volume grows.

We also evaluated the system's scalability to demonstrate that it maintains overall performance when operating on a large scale. As shown in Figure 15, the comparison of transaction time between the original smart contract and the smart contract with ECC reveals a steady and gradual increase in system transaction time as the number of vehicles increases, without reaching an uncontrollable state.

Figure 15.

Comparison of transaction time between the original smart contract and the smart contract with elliptic curve cryptosystem (ECC).

To evaluate the effectiveness of smart contracts, utilize the aforementioned performance evaluation methodology. Under typical load conditions, the proposed mechanism demonstrates satisfactory levels of performance. These tests provide insights into system feasibility, bottlenecks, and performance limitations, thus serving as a guide for future optimizations and enhancements.

Conclusions

With the popularity of blockchain and the IoV, the risk of transmitting data in wireless open space is gradually increasing. Since there is a scarcity of research on the utilization of smart contracts in the IoV, our research contribution stands out prominently.

This study presents a blockchain and smart contract framework with information security transmission mechanism for IoV. We use ECDH and ECDSA cryptosystems to protect transactions and smart contracts. Initially, the vehicle, base station, and cloud server in the IoV need to be registered and verified before they can join the operation of the IoV system. Afterward, this study employs the ECC and digital signature schemes to ensure the successful implementation of this proposed system, facilitating secure and automated transactions with the store through smart contracts. Therefore, in the case of encryption protection and identity verification, transactions can be secured. In addition, the secure transaction and smart contract architecture for IoV can not only achieve contactless transactions between users and stores but also ensure the security of transaction information and contracts through ECDH and ECDSA. The proposed architecture, incorporating ECDH and ECDSA security measures, may initially require more time for smart contract deployment to each EVM as the number of transactions increases. However, once the contract is written to the cloud server, subsequent transaction times become more efficient, resulting in a performance increase of up to 81%. Despite integrating additional security functions, CPU consumption only rises by 10%, memory by 0.69%, and storage by 3.4%. In addition, this study also compares the secure cross-chain mechanism proposed by Wu et al. The simulation results show that our mechanism is at least better than 3% in the consumption of transaction time, and at least better than 30% in the transaction throughput. Consequently, the approach of this study provides a secure architecture for blockchain and smart contracts that can initiate transactions autonomously while ensuring secure transmission and protection in the IoV.