# Trusted Blockchain-Based Signcryption Protocol and Data Management for Authentication and Authorization in VANETs

Authors: Jinqi Su; Runtao Ren; Yinghao Li; Raymond Y. K. Lau; Yikuan Shi
Journal: Wireless Communications and Mobile Computing
 (2022)

---

## Abstract

Vehicular Ad hoc Networks (VANETs) are the industrial cornerstone of intelligent transportation system (ITS), which are widely used in traffic management, automatic driving, and road optimization. With the expansion of the scale of the mobile ad hoc networks (MANETs) and smart vehicles (SV), VANETs will produce a large amount of data. In the open access environment of VANETs, the security of information transmission and the authenticity of user identity need to be considered when different vehicles communicate. In order to solve the cybersecurity risks of large-scale deployment of VANET, this paper proposes a trusted blockchain-based signcryption protocol and data management (TB-SCDM) for authentication and authorization (A&A) in VANETs. In the existing attack model, TB-SCDM can ensure the confidentiality and undeniability of information, as well as can effectively resist 51% attacks, eclipse attacks and double-spending attacks, etc. Through benchmark analysis, this scheme has higher computing efficiency and lower storage cost compared with other existing schemes.


---

## Body

## 1. Introduction

The VANETs have stimulated interest in both academic and industry, thanks to their intelligence and networking that assist vehicle driving and promote the application and development of ITS (e.g., automatic driving) [1–3]. At the same time, the VANETs have also become one of the most promising and fastest-growing subsets of the MANETs [4]. The VANETs are distributed and self-organized networks which communicate through wireless media, built up by SV, roadside units (RSUs), global positioning system (GPS), trusted authority (TA), and on-board units (OBUs). SV could communicate with each other as well as with roadside units (RSU) (e.g., electric toll collection of highways), which provide a good dedicated short-range communication (DSRC) by IEEE 802.11p standard for automatic driving technology to identify real-time traffic conditions [5–7]. TA is a third-party certification center used by the RSU and OBU that is responsible for controlling the whole network. RSU is a base station (e.g., Wi-Fi or WiMAX) that keeps as a central hub between the TA and the OBU and performs different authentications. The OBU is introduced on the vehicle to acquire procedure and exchange data identified with different vehicles and RSUs through DSRC.With the main goal of improving road safety and driving conditions, VANETs are established with five types of communications: the vehicle-to-vehicle (V2V), vehicle-to-roads (V2R), vehicle-to-infrastructure (V2I), roads-to-roads (R2R), and the roads-to-infrastructure (R2I) [8]. The architecture of VANETs is appeared in Figure 1. Due to the open nature of VANETs and lacking infrastructure, these delays establish reliable end-to-end communication paths and have efficient data transfer [9–10]. In particular, automatic driving technology has many system problems and security difficulties in obtaining availability, securing communication, and accessibility of exchange. In VANETs, SV are strangers who do not trust each other [11]. Without authentication and authorization, the attacker may impersonate any vehicle to broadcast forged messages to easily track the target vehicle by analyzing the broadcast messages, which will pose a serious threat [12]. Therefore, when the users of SV use automatic driving, they need to authenticate and authorize the identity of vehicle in VANETs.Figure 1
The architecture of VANETs.In the conventional A&A schemes, public key infrastructure- (PKI-) based solutions need a certificate authority (CA), while identification-based solutions require a key generation center (KGC) to provide vehicles with secure authentication [13–15]. However, there is a high computational overhead and large storage capacity on the CA and TA in the case of large number of certificates.Considering the above limitations, blockchain has the function of distributed storage, which can effectively realize decentralization [16–17]. The methods of automatically injecting trust, checking reliability, monitoring interentity communication, and analyzing behavior can be implemented in the blockchain. It forms a distributed database by using digital signature, encryption technology, hash function, and timestamp [18]. Blockchain assigns the responsibility of maintaining privacy and security to all entities in VANET instead of centralized operation [19–22]. In addition, identity-based signcryption protocol has shorter ciphertext and less computational overhead, which can sign and encrypt the data to ensure the confidentiality and nonrepudiation of the information [23–25].Our contribution: in automatic driving, since VANETs consist of a large number of SV at high speed, the security of information transmission must be satisfied A&A efficiently. In this paper, we propose a scheme that combined blockchain and signcryption to realize the A&A when the SV using automatic driving interacts with other media. Figure2 shows the physical process of TB-SCDM when the SV use automatic driving. The contributions of this article are as follows.
(1)
This article is an SV management system built on the consortium chain, which can upload the relevant data of SV to the blockchain to realize distributed storage(2)
The A&A function of SV users in ITS can be effectively realized in TB-SCDM scheme. The A&A mechanism we designed can ensure the trusted identity and effective authorization of SV users in VANETs(3)
The TB-SCDM scheme combines blockchain and signcryption. The data on the consortium chain cannot be tampered with arbitrarily. This mechanism provides a stronger security level for signing and encrypting the data that needs to be verified. Therefore, the confidentiality and unforgeability of SV information transmission in VANETs can be realized through TB-SCDMFigure 2
The process of TB-SCDM.


## 2. Preliminaries

### 2.1. Consortium Chains

Consortium chain has the advantages of weak concentration, high controllability, and great scalability [26]. Thanks to the number of nodes and organizational structure being relatively limited, consortium chain is mainly applied in systems built by specific organizations (e.g., data interaction of ITS). The rights of each participating node in the consortium chain are completely equal, and they can realize the trusted exchange of data. Each node of the consortium chain has a corresponding entity that wants to join and exit only to be executed after authorization. In the consortium chain, data transactions do not need the consensus of the whole blockchain network. Therefore, the consortium chain satisfies the data management requirements of VANETs through controlled access, efficient storage and trusted storage.


### 2.2. Smart Contract

Smart contract refers to a computer program that can be executed by a network of mutually untrusted nodes without any trusted authority. Compared with traditional programming source code, smart contracts utilize blockchain immutable distributed storage. In the initial stage of building the data storage system of SV, the vehicle management system can write triggers to realize the functions according to the actual needs. Once the system is put into operation, when the trigger conditions are met, the content of the smart contract can be executed to complete data upload, network access, and other processing functions. Finally, smart contracts can be developed to achieve smaller permission control granularity.


### 2.3. Practical Byzantine Fault Tolerance

The practical byzantine fault tolerance (PBFT) means a kind of fault tolerance of distributed network (i.e., the network can still make honest nodes reach a consensus. The PBFT mechanism will specify that one node in the system is the master node, and the other nodes are secondary nodes [27]. The process of PBFT is shown in Figure 3. When the primary node fails, all legal nodes in the system are eligible to upgrade from the secondary node to the primary node and follow the principle of the minority obeying the majority to ensure that honest nodes can reach a consensus. However, in order for the PBFT to operate normally, the number of malicious nodes must be less than 1/3 of the total number of nodes in the network. For example, in order to ensure the normal operation of the whole system, assuming that the number of invalid or malicious nodes tolerated by PBFT is F and the total number of nodes of the system is ∣R∣=3F+1, then 2F+1 normal nodes are required. Hence, the PBFT algorithm can tolerate less than 1/3 invalid or malicious nodes.Figure 3
The process of PBFT.


### 2.4. Meaning of Symbols

The specific meaning of the symbols is contained in Table1.Table 1
Specific meaning of symbols.
NotationsMeaningNiThe accountName of userIiThe identity of arbitrary userIKiThe userKey ofIiIDiThe userData ofIiIRiThe userResource ofIiPKiThe publicKey ofIiSKiThe secretKey ofIiδiThe digest ofIiMiThe plainText ofIiCiThe cipherText ofIiμiThe signature ofIi𝜎iThe signcryption ofIiσIRiThe signcryptedUserResource ofIi


## 2.1. Consortium Chains

Consortium chain has the advantages of weak concentration, high controllability, and great scalability [26]. Thanks to the number of nodes and organizational structure being relatively limited, consortium chain is mainly applied in systems built by specific organizations (e.g., data interaction of ITS). The rights of each participating node in the consortium chain are completely equal, and they can realize the trusted exchange of data. Each node of the consortium chain has a corresponding entity that wants to join and exit only to be executed after authorization. In the consortium chain, data transactions do not need the consensus of the whole blockchain network. Therefore, the consortium chain satisfies the data management requirements of VANETs through controlled access, efficient storage and trusted storage.


## 2.2. Smart Contract

Smart contract refers to a computer program that can be executed by a network of mutually untrusted nodes without any trusted authority. Compared with traditional programming source code, smart contracts utilize blockchain immutable distributed storage. In the initial stage of building the data storage system of SV, the vehicle management system can write triggers to realize the functions according to the actual needs. Once the system is put into operation, when the trigger conditions are met, the content of the smart contract can be executed to complete data upload, network access, and other processing functions. Finally, smart contracts can be developed to achieve smaller permission control granularity.


## 2.3. Practical Byzantine Fault Tolerance

The practical byzantine fault tolerance (PBFT) means a kind of fault tolerance of distributed network (i.e., the network can still make honest nodes reach a consensus. The PBFT mechanism will specify that one node in the system is the master node, and the other nodes are secondary nodes [27]. The process of PBFT is shown in Figure 3. When the primary node fails, all legal nodes in the system are eligible to upgrade from the secondary node to the primary node and follow the principle of the minority obeying the majority to ensure that honest nodes can reach a consensus. However, in order for the PBFT to operate normally, the number of malicious nodes must be less than 1/3 of the total number of nodes in the network. For example, in order to ensure the normal operation of the whole system, assuming that the number of invalid or malicious nodes tolerated by PBFT is F and the total number of nodes of the system is ∣R∣=3F+1, then 2F+1 normal nodes are required. Hence, the PBFT algorithm can tolerate less than 1/3 invalid or malicious nodes.Figure 3
The process of PBFT.


## 2.4. Meaning of Symbols

The specific meaning of the symbols is contained in Table1.Table 1
Specific meaning of symbols.
NotationsMeaningNiThe accountName of userIiThe identity of arbitrary userIKiThe userKey ofIiIDiThe userData ofIiIRiThe userResource ofIiPKiThe publicKey ofIiSKiThe secretKey ofIiδiThe digest ofIiMiThe plainText ofIiCiThe cipherText ofIiμiThe signature ofIi𝜎iThe signcryption ofIiσIRiThe signcryptedUserResource ofIi


## 3. Formation Definition

### 3.1. Syntax

The algorithm definition of TB-SCDM is as follows.Initialize (1θ) → Table: the initialize algorithm is executed by an administrator in the securable environment. Firstly, the administrator has a query for system and takes as input a security parameter θ, then return a local table named management and output 0 otherwise.BlockUp (Table) →1 or 0: the BlockUp algorithm is run by the administrator as well. For this algorithm, administrator sends each primary key Ni,Ii,IDi,IKi,IRi,PKi,Ci,μi,σi,σIRi to table for achieving consensus among nodes then output 1 or 0.Signcrypt (Ni,IDi,IKi) → PKi,SKi: the Keygen algorithm is performed by one user who tries to register a new account in the system. The user sends Ni, IDi, and IKi to the system to generate PKi, SKi, and σi. Then, PKi, SKi,Ci, δi, μi, and σi will be saved in the table for connecting blockchain.Authentication (Ni,IKi,SKi) →1 or 0: this user sends Ni∗, IKi∗, and SKi∗ to the system to produce digest δi∗ and δi∗∗ for validation. There are two cases in this process.Case 1.
Ifδi∗=δi∗∗, the user can realize the login process to show that the user’s identity information is reliable.Case 2.
Ifδi∗≠δi∗∗, the authentication of this user with identity is failed and output 0.Update (IRi,SKi) →σIRi: this algorithm is executed by the user who needs to update the resource in the system. Assume the identity of user is valid, the IRi and SKi can get input by this user to output signcryptedUserResourceσIRion the block.Authorization (Ni,PKi) → IRi or 0: this Authorization algorithm is to realize the authorization of users. Initially, the user should send the target account Ni∗ and the corresponding public key PKi∗ to platform for verification. There are two cases in this algorithm.Case 1.
Ifδi∗=δi∗∗, the user can be authorized and gain the part access for userResource IRi.Case 2.
Ifδi∗≠δi∗∗, this user failed to authorization and output 0.Conversation (Ni,PKi) →1 or 0: the algorithm is used to establish dialogue between different users. First, the user can send Ni and PKi∗ to platform for communication. There are two situations in this algorithm.Case 1.
Ifδi∗=δi∗∗, the user can be authorized and gain a conversation.Case 2.
Ifδi∗≠δi∗∗, instant messaging channel cannot establish and output 0.Transaction (Chain) → transactionHash: this algorithm is run by administrator in order to obtain the information on the blockchain. The administrator can query the main parameters of the blockchain to get buildTime, buildType, genesisBlockHash and contractAddress, etc.


## 3.1. Syntax

The algorithm definition of TB-SCDM is as follows.Initialize (1θ) → Table: the initialize algorithm is executed by an administrator in the securable environment. Firstly, the administrator has a query for system and takes as input a security parameter θ, then return a local table named management and output 0 otherwise.BlockUp (Table) →1 or 0: the BlockUp algorithm is run by the administrator as well. For this algorithm, administrator sends each primary key Ni,Ii,IDi,IKi,IRi,PKi,Ci,μi,σi,σIRi to table for achieving consensus among nodes then output 1 or 0.Signcrypt (Ni,IDi,IKi) → PKi,SKi: the Keygen algorithm is performed by one user who tries to register a new account in the system. The user sends Ni, IDi, and IKi to the system to generate PKi, SKi, and σi. Then, PKi, SKi,Ci, δi, μi, and σi will be saved in the table for connecting blockchain.Authentication (Ni,IKi,SKi) →1 or 0: this user sends Ni∗, IKi∗, and SKi∗ to the system to produce digest δi∗ and δi∗∗ for validation. There are two cases in this process.Case 1.
Ifδi∗=δi∗∗, the user can realize the login process to show that the user’s identity information is reliable.Case 2.
Ifδi∗≠δi∗∗, the authentication of this user with identity is failed and output 0.Update (IRi,SKi) →σIRi: this algorithm is executed by the user who needs to update the resource in the system. Assume the identity of user is valid, the IRi and SKi can get input by this user to output signcryptedUserResourceσIRion the block.Authorization (Ni,PKi) → IRi or 0: this Authorization algorithm is to realize the authorization of users. Initially, the user should send the target account Ni∗ and the corresponding public key PKi∗ to platform for verification. There are two cases in this algorithm.Case 1.
Ifδi∗=δi∗∗, the user can be authorized and gain the part access for userResource IRi.Case 2.
Ifδi∗≠δi∗∗, this user failed to authorization and output 0.Conversation (Ni,PKi) →1 or 0: the algorithm is used to establish dialogue between different users. First, the user can send Ni and PKi∗ to platform for communication. There are two situations in this algorithm.Case 1.
Ifδi∗=δi∗∗, the user can be authorized and gain a conversation.Case 2.
Ifδi∗≠δi∗∗, instant messaging channel cannot establish and output 0.Transaction (Chain) → transactionHash: this algorithm is run by administrator in order to obtain the information on the blockchain. The administrator can query the main parameters of the blockchain to get buildTime, buildType, genesisBlockHash and contractAddress, etc.


## 4. Concrete Scheme

There are eight parts in the TB-SCDM: Initialize, BlockUp, Signcrypt, Authentication, Update, Authorization, Conversation, and Transaction. The steps of Authentication, Update, and Authorization are described in Figure4.Figure 4
The process of Authentication, Update, and Authorization.


### 4.1. Initialize

This algorithm is to register a table named management on the blockchain so that later users’ information can be registered on the consortium chain.Algorithm 1: Initialize.
Input:1θOutput: TablecreateTable() private{tf.createTable(“management”, “Ii”, “Ni”, “IDi”, “IKi”, “PKi”, “μi”, “Ci”, “σi”, “IRi”, “σIRi”);}openTable() private returns(table){TableFactorytf=TableFactory0x1001;Tabletable=tf.openTable“management”;return table;}


### 4.2. BlockUp

This algorithm is executed by the administrator. Its purpose is to create each primary key in the table generated in algorithm1 and then upload the data of each primary key to the blockchain.Algorithm 2: BlockUp.
Input:Ii, Ni, IDi, IKi, PKi, μi, Ci, σi, IRi, σIRiOutput: true or falsestatu = select(management)if(statu !==0) {Table table = openTable();Entry entry = table.newEntry();entry.set("Ii, Ni, IDi, IKi, PKi, μi, Ci, σi, IRi”", Ii, Ni, IDi, IKi, PKi, μi, Ci, σi, IRi);return True;} else {return false;}


### 4.3. Signcrypt

Firstly, the system will first give a public-private key pair to the user with identityIi. Accordingly, the user will deposit the Ii, IDi, and IKi in the plainText Mi to generate the hash value δi. Then, this user utilizes the private key SKi to produce the signature μi and utilizes the public key PKi to encrypt Mi for getting the ciphertext Ci. Finally, μi and Ci will be merged to return the signcryption σi.Algorithm 3: Signcrypt.
Input:Ni, IDi, IKiOutput: PKi, SKiFunction SignCrypted Input(Mi, SKi) Output(δi, μi, Ci, σi){δi = Method.hash(Mi);μi = Method.sign(δi, SKi);Ci = homomorphicEncryption.Enc(Mi);σi = signcrypt(μi || Ci);}statu = select(Ni);if(statu !==0) {Get cryptographic KeyPair = new createKeyPair();Get cryptographic Method = new cryptographic (CryptoType.SCHNORRTYPE);PKi = KeyPair.getPKi ();SKi = KeyPair.getSKi ();Mi = Ii || IDi || IKi;δi || μi || Ci || σi = function.SignCrypted(Mi, SKi);entry.set("Ni, IDi, IKi, PKi, μi, Ci, σi”", Ni, IDi, IKi, PKi, μi, Ci, σi);count = table.insert(Ni, entry);if (count ==1) {statu_code = true;} else {statu_code = false;}} else {statu_code = false;}return statu_codePKiSKi;


### 4.4. Authentication

For Authentication algorithm, the user of identityIi can input Ni∗, IKi∗, and SKi∗ in the system and then query whether there exists the account named Ni∗ in the table. If exist Ni∗, this user will enter the authentication stage.On the client side, the (Ii, IDi, and IKi*) will deposit in plainText Mi to produce the hash value δi∗. Accordingly, the signature μi∗ can be generated by the private key SKi∗.On the blockchain side, the signatureμi∗ can be unsigned by the trusted public key PKi stored by previous user of identity Ii. Accordingly, the trusted signcryption σi can be unsigncrypted to get the hash value δi∗∗. After obtaining the above data, the next step will verify the user’s identity. There are two cases in this process.Case 1.
Ifδi∗=δi∗∗, the user can realize the login process to show that the user’s identity information is reliable.Case 2.
Ifδi∗≠δi∗∗, the authentication of this user with identity is failed and output 0.Algorithm 4: Authentication
Input:Ni, IKi, SKiOutput: true or falseFunction unSignCrypted Input(σi, PKi) Output(true or false){'μi’' || 'Ci∗∗' = unsigncrypt(σi);if('μi∗' == 0) {'μi∗' = 'μi’';}'δi∗' = Method.unsign('μi∗', PKi);'Mi∗∗' = homomorphicEncryption.Dec('Ci∗∗');'δi∗∗' = Method.hash('Mi∗∗');if('δi∗' == 'δi∗∗') {statu_code = true;} else {statu_code = false;}}statu = select(Ni);if(statu !==0) {Get cryptographic Method = new cryptographic (CryptoType.SCHNORRTYPE);'IKi∗' = result.getValue2();'SKi∗' = result.getValue3();'Mi∗' = Ii || IDi || 'IKi∗';'δi∗' = Method.hash('Mi∗');'μi∗' = Method.sign('δi∗', 'SKi∗');statu_code = function.unSignCrypted(σi, PKi);} else {statu_code = false;}return statu_code;


### 4.5. Update

The user of identityIi can update the resource in the system through this algorithm. The user can input IRi and SKi in the system. Then, Ii, PKi, and IRi will be merged into the plainText Mi. The following queries are same as those in Algorithm 1.Finally, the updated information of these users will be uploaded to consortium chain.Algorithm 5: Update.
Input:IRi, SKiOutput: true or falseGet cryptographic Method = new cryptographic (CryptoType.SCHNORRTYPE);Mi = Ii || PKi || IRi;δi || μi || Ci || σIRi = function.SignCrypted(Mi, SKi);enter.set("IRi, σIRi”", IRi, σIRi);count = table.insert(IRi, σIRi, entry);if (count ==1) {return true;} else {return false;}


### 4.6. Authorization

This algorithm is designed to authorize the legitimacy of user’s behavior. In the authorization process, we add the token technology. In this mechanism, we first set the upper limit of the user’s single query time to 300 s.After exceeding the time, the user’s access rights will disconnected, and his identity needs to be verified newly. Within legal time, accountNi∗ will be first verified for existence. If account Ni∗ exists, then the user of identity Ii will enter the authentication stage for authorization.On the blockchain side, the trusted signcryptionσi can be unsigncrypted to return the signature μi∗ and ciphertext Ci∗∗. Accordingly, the signature μi∗ can be unsigned to get the hash value δi∗. And the ciphertext Ci∗∗ can be decrypted to acquire δi∗∗. After obtaining the above data, the next step will enter to the validation. There are two cases in this process.Case 1.
Ifδi∗=δi∗∗, the user can be authorized and gain the part access for userResource IRi.Case 2.
Ifδi∗≠δi∗∗, this user failed to authorization and output 0.Algorithm 6: Authorization.
Input:Ni, PKiOutput:IRitimeStamp = System.TimeSeconds();expireTime = System.TimeSeconds() - timeStamp;If(expireTime <300) {Statu = select(Ni);If(statu! =0) {‘PKi∗’ = result.getValue2();statu_code = function.unSignCrypted(σIRi, ‘PKi∗’);If(statu_code ==1) {ReturnIRi;}}}


### 4.7. Conversation

Before two users establish a session, the system will set the maximum time limit for a single query to 300 s. After exceeding the time, it will be disconnected automatically and need to be verified again. During the verification process, accountNi∗ will be queried whether exist. The following queries are same as those in Algorithm 5.Algorithm 7: Conversation
Input:Ni, PKiOutput: true or falsetimeStamp = System.TimeSeconds();expireTime = System.TimeSeconds() - timeStamp;if(expireTime < 300) {statu = select(Ni);if(statu !==0) {'PKi∗' = result.getValue2();statu_code = function.unSignCrypted(σi, 'PKi∗');if(statu_code ==1) {creat.Conversation(Ni);return true;}}}


### 4.8. Transaction

The administrator can query the main parameters of the blockchain to get buildTime, buildType, genesisBlockHash and contractAddress, etc. These data are unique and cannot be tampered with arbitrarily.Algorithm 8: Transaction
Input: getchainVersionOutput: buildTime, buildType, genesisHash, etc.[group:1]> getNodeVersionClientVersion{version='2.8.0',supportedVersion='2.8.0',chainId='1',buildTime='20210830 12:52:15',buildType='Linux/clang/Release',gitBranch='HEAD',genesisHash='bf0e0242a8040ead7549de49423712233a36d1b51b056a1c20df5eb78a9613e5'}transaction hash: 0xe88c2b9bf6dec9fa10356fd75b3d5414a5bd48f7ca246a8134e7f877928c47fccontract address: 0x48102a5d29a6109384cb5a9c97d9fd07dd1a4416currentAccount: 0xb13d80305a847dd2160c71465b50a6a1c0506ee3[group:1]> getBlockNumber9[group:1]> getCurrentAccount0xb13d80305a847dd2160c71465b50a6a1c0506ee3


## 4.1. Initialize

This algorithm is to register a table named management on the blockchain so that later users’ information can be registered on the consortium chain.Algorithm 1: Initialize.
Input:1θOutput: TablecreateTable() private{tf.createTable(“management”, “Ii”, “Ni”, “IDi”, “IKi”, “PKi”, “μi”, “Ci”, “σi”, “IRi”, “σIRi”);}openTable() private returns(table){TableFactorytf=TableFactory0x1001;Tabletable=tf.openTable“management”;return table;}


## 4.2. BlockUp

This algorithm is executed by the administrator. Its purpose is to create each primary key in the table generated in algorithm1 and then upload the data of each primary key to the blockchain.Algorithm 2: BlockUp.
Input:Ii, Ni, IDi, IKi, PKi, μi, Ci, σi, IRi, σIRiOutput: true or falsestatu = select(management)if(statu !==0) {Table table = openTable();Entry entry = table.newEntry();entry.set("Ii, Ni, IDi, IKi, PKi, μi, Ci, σi, IRi”", Ii, Ni, IDi, IKi, PKi, μi, Ci, σi, IRi);return True;} else {return false;}


## 4.3. Signcrypt

Firstly, the system will first give a public-private key pair to the user with identityIi. Accordingly, the user will deposit the Ii, IDi, and IKi in the plainText Mi to generate the hash value δi. Then, this user utilizes the private key SKi to produce the signature μi and utilizes the public key PKi to encrypt Mi for getting the ciphertext Ci. Finally, μi and Ci will be merged to return the signcryption σi.Algorithm 3: Signcrypt.
Input:Ni, IDi, IKiOutput: PKi, SKiFunction SignCrypted Input(Mi, SKi) Output(δi, μi, Ci, σi){δi = Method.hash(Mi);μi = Method.sign(δi, SKi);Ci = homomorphicEncryption.Enc(Mi);σi = signcrypt(μi || Ci);}statu = select(Ni);if(statu !==0) {Get cryptographic KeyPair = new createKeyPair();Get cryptographic Method = new cryptographic (CryptoType.SCHNORRTYPE);PKi = KeyPair.getPKi ();SKi = KeyPair.getSKi ();Mi = Ii || IDi || IKi;δi || μi || Ci || σi = function.SignCrypted(Mi, SKi);entry.set("Ni, IDi, IKi, PKi, μi, Ci, σi”", Ni, IDi, IKi, PKi, μi, Ci, σi);count = table.insert(Ni, entry);if (count ==1) {statu_code = true;} else {statu_code = false;}} else {statu_code = false;}return statu_codePKiSKi;


## 4.4. Authentication

For Authentication algorithm, the user of identityIi can input Ni∗, IKi∗, and SKi∗ in the system and then query whether there exists the account named Ni∗ in the table. If exist Ni∗, this user will enter the authentication stage.On the client side, the (Ii, IDi, and IKi*) will deposit in plainText Mi to produce the hash value δi∗. Accordingly, the signature μi∗ can be generated by the private key SKi∗.On the blockchain side, the signatureμi∗ can be unsigned by the trusted public key PKi stored by previous user of identity Ii. Accordingly, the trusted signcryption σi can be unsigncrypted to get the hash value δi∗∗. After obtaining the above data, the next step will verify the user’s identity. There are two cases in this process.Case 1.
Ifδi∗=δi∗∗, the user can realize the login process to show that the user’s identity information is reliable.Case 2.
Ifδi∗≠δi∗∗, the authentication of this user with identity is failed and output 0.Algorithm 4: Authentication
Input:Ni, IKi, SKiOutput: true or falseFunction unSignCrypted Input(σi, PKi) Output(true or false){'μi’' || 'Ci∗∗' = unsigncrypt(σi);if('μi∗' == 0) {'μi∗' = 'μi’';}'δi∗' = Method.unsign('μi∗', PKi);'Mi∗∗' = homomorphicEncryption.Dec('Ci∗∗');'δi∗∗' = Method.hash('Mi∗∗');if('δi∗' == 'δi∗∗') {statu_code = true;} else {statu_code = false;}}statu = select(Ni);if(statu !==0) {Get cryptographic Method = new cryptographic (CryptoType.SCHNORRTYPE);'IKi∗' = result.getValue2();'SKi∗' = result.getValue3();'Mi∗' = Ii || IDi || 'IKi∗';'δi∗' = Method.hash('Mi∗');'μi∗' = Method.sign('δi∗', 'SKi∗');statu_code = function.unSignCrypted(σi, PKi);} else {statu_code = false;}return statu_code;


## 4.5. Update

The user of identityIi can update the resource in the system through this algorithm. The user can input IRi and SKi in the system. Then, Ii, PKi, and IRi will be merged into the plainText Mi. The following queries are same as those in Algorithm 1.Finally, the updated information of these users will be uploaded to consortium chain.Algorithm 5: Update.
Input:IRi, SKiOutput: true or falseGet cryptographic Method = new cryptographic (CryptoType.SCHNORRTYPE);Mi = Ii || PKi || IRi;δi || μi || Ci || σIRi = function.SignCrypted(Mi, SKi);enter.set("IRi, σIRi”", IRi, σIRi);count = table.insert(IRi, σIRi, entry);if (count ==1) {return true;} else {return false;}


## 4.6. Authorization

This algorithm is designed to authorize the legitimacy of user’s behavior. In the authorization process, we add the token technology. In this mechanism, we first set the upper limit of the user’s single query time to 300 s.After exceeding the time, the user’s access rights will disconnected, and his identity needs to be verified newly. Within legal time, accountNi∗ will be first verified for existence. If account Ni∗ exists, then the user of identity Ii will enter the authentication stage for authorization.On the blockchain side, the trusted signcryptionσi can be unsigncrypted to return the signature μi∗ and ciphertext Ci∗∗. Accordingly, the signature μi∗ can be unsigned to get the hash value δi∗. And the ciphertext Ci∗∗ can be decrypted to acquire δi∗∗. After obtaining the above data, the next step will enter to the validation. There are two cases in this process.Case 1.
Ifδi∗=δi∗∗, the user can be authorized and gain the part access for userResource IRi.Case 2.
Ifδi∗≠δi∗∗, this user failed to authorization and output 0.Algorithm 6: Authorization.
Input:Ni, PKiOutput:IRitimeStamp = System.TimeSeconds();expireTime = System.TimeSeconds() - timeStamp;If(expireTime <300) {Statu = select(Ni);If(statu! =0) {‘PKi∗’ = result.getValue2();statu_code = function.unSignCrypted(σIRi, ‘PKi∗’);If(statu_code ==1) {ReturnIRi;}}}


## 4.7. Conversation

Before two users establish a session, the system will set the maximum time limit for a single query to 300 s. After exceeding the time, it will be disconnected automatically and need to be verified again. During the verification process, accountNi∗ will be queried whether exist. The following queries are same as those in Algorithm 5.Algorithm 7: Conversation
Input:Ni, PKiOutput: true or falsetimeStamp = System.TimeSeconds();expireTime = System.TimeSeconds() - timeStamp;if(expireTime < 300) {statu = select(Ni);if(statu !==0) {'PKi∗' = result.getValue2();statu_code = function.unSignCrypted(σi, 'PKi∗');if(statu_code ==1) {creat.Conversation(Ni);return true;}}}


## 4.8. Transaction

The administrator can query the main parameters of the blockchain to get buildTime, buildType, genesisBlockHash and contractAddress, etc. These data are unique and cannot be tampered with arbitrarily.Algorithm 8: Transaction
Input: getchainVersionOutput: buildTime, buildType, genesisHash, etc.[group:1]> getNodeVersionClientVersion{version='2.8.0',supportedVersion='2.8.0',chainId='1',buildTime='20210830 12:52:15',buildType='Linux/clang/Release',gitBranch='HEAD',genesisHash='bf0e0242a8040ead7549de49423712233a36d1b51b056a1c20df5eb78a9613e5'}transaction hash: 0xe88c2b9bf6dec9fa10356fd75b3d5414a5bd48f7ca246a8134e7f877928c47fccontract address: 0x48102a5d29a6109384cb5a9c97d9fd07dd1a4416currentAccount: 0xb13d80305a847dd2160c71465b50a6a1c0506ee3[group:1]> getBlockNumber9[group:1]> getCurrentAccount0xb13d80305a847dd2160c71465b50a6a1c0506ee3


## 5. Theoretical Analysis

### 5.1. Security Proof of Blockchain

#### 5.1.1. Eclipse Attack

The multinode consortium blockchain system of TB-SCDM is built based on the FISCO BCOS platform. The system has a node access mechanism, so it is difficult for attackers to obtain legitimate nodes through normal channels. Therefore, it is difficult for attackers to obtain legal nodes through normal channels. The PBFT mechanism of the TB-SCDM determines that if one third of the nodes of the system operate normally, it will not affect the normal operation of the whole system. Even if the attacker obtains the permissions of multiple accounting nodes, then the attacked node will be quickly discovered and processed by the central node.


#### 5.1.2. DOS/DDoS Prevention

TB-SCDM adopts the consensus algorithm mechanism of consortium blockchain and PBFT. Therefore, the attack on ordinary nodes without accounting permission cannot hinder the normal operation of the blockchain system. Due to the characteristics of PBFT consistency algorithm mechanism, as long as there are more than one-third of normal nodes in the system, the system can operate normally, which leads to a huge inverse ratio between the attack cost and benefit of DDoS/DOS. However, for the consortium blockchain of TB-SCDM, the time and cost of discovering and repairing accounting nodes are very small.


#### 5.1.3. 51% Attack Prevention

For the consortium blockchain, the greater the computing power of all nodes, the more difficult to implement 51% attacks. It is hard for attackers to break more than 51% of nodes in a short time, and it is difficult to complete the destruction of the ledger before the central node takes corresponding countermeasures. Even if the ledger is attacked, the central node can repair the ledger in a very short time.


#### 5.1.4. Sybil Attack Prevention

Each registered user will generate a unique public-private key pair. Each node needs a unique and unforgeable public key when uploading or updating the data on blockchain. Therefore, any attacker cannot use a single forged public key to disguise as multiple users and occupy all links of a billing node.


### 5.2. Security Proof of Signcryption

#### 5.2.1. Identity Authentication

The system binds the user’s public key with the user ID and then provides it to the user for safekeeping in the user registration stage. In addition, the signcryption method bound with the user’s public key is adopted in the process of chaining or reading all information, which ensures the traceability of the system to the data and the authentication of the identity.


#### 5.2.2. Confidentiality

Compared with the traditional digital signature, this paper adopts the signcryption technology based on Schnorr. Many literatures have verified the IND-CCA security (i.e., indistinguishability under the adaptive chosen-ciphertext attacks) based on Schnorr under the random oracles or standard oracles. Through the analysis of provable security theory, signcryption technology can effectively ensure the confidentiality of information in the process of transmission.


#### 5.2.3. Unforgeability

TB-SCDM verifies whether the transmitted message comes from the real sender by verifying the message digest of the sender and receiver. We generate the compared message digest by storing the public key and trusted data in the blockchain. If the message digest is the same as the sender’s message digest, verification can be realized to achieve UF-CMA security (i.e., existentially unforgeable under the adaptive chosen-message attacks). This article innovatively integrates signcryption, timestamp, and blockchain based on Schnorr to ensure the unforgeability of information.


## 5.1. Security Proof of Blockchain

### 5.1.1. Eclipse Attack

The multinode consortium blockchain system of TB-SCDM is built based on the FISCO BCOS platform. The system has a node access mechanism, so it is difficult for attackers to obtain legitimate nodes through normal channels. Therefore, it is difficult for attackers to obtain legal nodes through normal channels. The PBFT mechanism of the TB-SCDM determines that if one third of the nodes of the system operate normally, it will not affect the normal operation of the whole system. Even if the attacker obtains the permissions of multiple accounting nodes, then the attacked node will be quickly discovered and processed by the central node.


### 5.1.2. DOS/DDoS Prevention

TB-SCDM adopts the consensus algorithm mechanism of consortium blockchain and PBFT. Therefore, the attack on ordinary nodes without accounting permission cannot hinder the normal operation of the blockchain system. Due to the characteristics of PBFT consistency algorithm mechanism, as long as there are more than one-third of normal nodes in the system, the system can operate normally, which leads to a huge inverse ratio between the attack cost and benefit of DDoS/DOS. However, for the consortium blockchain of TB-SCDM, the time and cost of discovering and repairing accounting nodes are very small.


### 5.1.3. 51% Attack Prevention

For the consortium blockchain, the greater the computing power of all nodes, the more difficult to implement 51% attacks. It is hard for attackers to break more than 51% of nodes in a short time, and it is difficult to complete the destruction of the ledger before the central node takes corresponding countermeasures. Even if the ledger is attacked, the central node can repair the ledger in a very short time.


### 5.1.4. Sybil Attack Prevention

Each registered user will generate a unique public-private key pair. Each node needs a unique and unforgeable public key when uploading or updating the data on blockchain. Therefore, any attacker cannot use a single forged public key to disguise as multiple users and occupy all links of a billing node.


## 5.1.1. Eclipse Attack

The multinode consortium blockchain system of TB-SCDM is built based on the FISCO BCOS platform. The system has a node access mechanism, so it is difficult for attackers to obtain legitimate nodes through normal channels. Therefore, it is difficult for attackers to obtain legal nodes through normal channels. The PBFT mechanism of the TB-SCDM determines that if one third of the nodes of the system operate normally, it will not affect the normal operation of the whole system. Even if the attacker obtains the permissions of multiple accounting nodes, then the attacked node will be quickly discovered and processed by the central node.


## 5.1.2. DOS/DDoS Prevention

TB-SCDM adopts the consensus algorithm mechanism of consortium blockchain and PBFT. Therefore, the attack on ordinary nodes without accounting permission cannot hinder the normal operation of the blockchain system. Due to the characteristics of PBFT consistency algorithm mechanism, as long as there are more than one-third of normal nodes in the system, the system can operate normally, which leads to a huge inverse ratio between the attack cost and benefit of DDoS/DOS. However, for the consortium blockchain of TB-SCDM, the time and cost of discovering and repairing accounting nodes are very small.


## 5.1.3. 51% Attack Prevention

For the consortium blockchain, the greater the computing power of all nodes, the more difficult to implement 51% attacks. It is hard for attackers to break more than 51% of nodes in a short time, and it is difficult to complete the destruction of the ledger before the central node takes corresponding countermeasures. Even if the ledger is attacked, the central node can repair the ledger in a very short time.


## 5.1.4. Sybil Attack Prevention

Each registered user will generate a unique public-private key pair. Each node needs a unique and unforgeable public key when uploading or updating the data on blockchain. Therefore, any attacker cannot use a single forged public key to disguise as multiple users and occupy all links of a billing node.


## 5.2. Security Proof of Signcryption

### 5.2.1. Identity Authentication

The system binds the user’s public key with the user ID and then provides it to the user for safekeeping in the user registration stage. In addition, the signcryption method bound with the user’s public key is adopted in the process of chaining or reading all information, which ensures the traceability of the system to the data and the authentication of the identity.


### 5.2.2. Confidentiality

Compared with the traditional digital signature, this paper adopts the signcryption technology based on Schnorr. Many literatures have verified the IND-CCA security (i.e., indistinguishability under the adaptive chosen-ciphertext attacks) based on Schnorr under the random oracles or standard oracles. Through the analysis of provable security theory, signcryption technology can effectively ensure the confidentiality of information in the process of transmission.


### 5.2.3. Unforgeability

TB-SCDM verifies whether the transmitted message comes from the real sender by verifying the message digest of the sender and receiver. We generate the compared message digest by storing the public key and trusted data in the blockchain. If the message digest is the same as the sender’s message digest, verification can be realized to achieve UF-CMA security (i.e., existentially unforgeable under the adaptive chosen-message attacks). This article innovatively integrates signcryption, timestamp, and blockchain based on Schnorr to ensure the unforgeability of information.


## 5.2.1. Identity Authentication

The system binds the user’s public key with the user ID and then provides it to the user for safekeeping in the user registration stage. In addition, the signcryption method bound with the user’s public key is adopted in the process of chaining or reading all information, which ensures the traceability of the system to the data and the authentication of the identity.


## 5.2.2. Confidentiality

Compared with the traditional digital signature, this paper adopts the signcryption technology based on Schnorr. Many literatures have verified the IND-CCA security (i.e., indistinguishability under the adaptive chosen-ciphertext attacks) based on Schnorr under the random oracles or standard oracles. Through the analysis of provable security theory, signcryption technology can effectively ensure the confidentiality of information in the process of transmission.


## 5.2.3. Unforgeability

TB-SCDM verifies whether the transmitted message comes from the real sender by verifying the message digest of the sender and receiver. We generate the compared message digest by storing the public key and trusted data in the blockchain. If the message digest is the same as the sender’s message digest, verification can be realized to achieve UF-CMA security (i.e., existentially unforgeable under the adaptive chosen-message attacks). This article innovatively integrates signcryption, timestamp, and blockchain based on Schnorr to ensure the unforgeability of information.


## 6. Benchmark Test

### 6.1. Benchmark Test of Blockchain

In order to efficiently perform operations, we accessed the data on TB-SCDM using the CRUD interface supplied by FISCO BCOS 2.0. The hardware environment is an Intel i5-8265U 1.80 GHz computer, 16 GB of memory, and running Windows 10 operating system.It is available to deploy several different nodes on the same server for a test chain, we used a Linux server to deploy six nodes. For the smart contract of the blockchain, we chose the solidity language. This paper adopts Caliper as the test script to test the smart contract of consortium blockchain. The consortium blockchain is composed of a single group of six nodes. We select the scenario of 10000 concurrent transactions and 1000 new user registrations. The performance objects tested include memory usage, CPU usage, data traffic, disk read and write volume of each node, etc.The performance metrics of send rate, latency, and throughput are described in Table2. Figure 5 shows the memory usage of each node when processing data. Figure 6 shows the CPU usage of each node when verifying information. Figure 7 shows the traffic required for each node to form a consensus. Figure 8 shows the amount of traffic required by each node to form a consensus on the hard disk.Table 2
The performance metrics of send rate, latency, and throughput.
NameSuccFailSend rate (TPS)Max latency(s)Min latency(s)Avg latency(s)Throughput (TPS)User10000606.22.160.321.52371.6Transfer100000976.618.351.3312.25509.7Figure 5
Memory usage of each node.Figure 6
CPU usage of each node.Figure 7
Traffic required for each node.Figure 8
Disc read and write amount of each node.


### 6.2. Benchmark Test of Signcryption

The TB-SCDM and previous schemes [28–31] are exploited by the jPBC library on a laptop, where the configuration is a Windows 11 operating system, 2.60 GHz Intel(R) Core(TM) i7-9750H CPU with 16-GB RAM.The meaning of the operation symbols is described in Table3. The performance comparison of different schemes is described in Table 4.Table 3
Symbols and descriptions of various operational times.
SymbolsMeaningOMThe time of a multiplication operation, 1OM≈1.25msOPThe time of a bilinear pairing operations, 1OP≈32.23msTable 4
Performance comparison with other schemes.
SchemesSigncryption costUnsigncryption costExecutiontime/n=1000ConfidentialityUnforgeabilityIqbal et al. [28]4nOMnOM+nOP5nOM+nOP/71980ms√√Cui et al. [29]nOP2nOM+2nOP3nOM+2nOP/166090ms√√Hong et al. [30]n3OM+OPn3OM+OP6nOM+2nOP/8820ms√√Du et al. [31]4nOM4nOM8nOM/8820ms√√TB-SCDM2nOMnOM3nOM/2520ms√√A simple and intuitive method can be adopted in order to estimate the computation efficiency of the computational of several schemes. In terms of overall cryptographic operations, we can find that Iqbal et al. [28] is 5nOM+nOP, Cui et al. [29] is 3nOM+2nOP, Hong et al. [30] is 6nOM+2nOP, Du et al. [31] is 8nOM, and TB-SCDM is 3nOM. From the perspective of formula, the cost efficiency of TB-SCDM is the highest.Figures9 and 10 describe the execution time of different schemes when n changes from 100 to 1000. From the perspective of change range, it can be seen that when the number of users gradually increases, the computational efficiency of TB-SCDM is more obvious than other schemes.Figure 9
Comparison of signcryption cost.Figure 10
Comparison of unsigncryption cost.In Figure11, in order to compare various schemes more clearly, we specially select the execution time of signcryption, unsigncryption, and total operations when the number of users n equals 1000. The execution times of signcryption operations are as follows: the running time of Iqbal et al. [28] is 4×1000×1.25=5000ms, the running time of Cui et al. [29] is 1000×32.23=32230ms, the running time of Hong et al. [30] is 1000×3×1.25+1000×32.23=35980ms, the running time of Du et al. [31] is 4×1000×1.25=5000ms, and the running time of TB-SCDM is 2×1000×1.25=2500ms.Figure 11
Comparison of total time (n=1000).The execution times of unsigncryption operations are as follows: the running time of Iqbal et al. [28] is 1000×1.25+1000×32.23=33480 ms, the running time of Cui et al. [29] is 2×1000×1.25+2×1000×32.23=66960ms, the running time of Hong et al. [30] is 1000×3×1.25+1000×32.23=35980ms, the running time of Du et al. [31] is 4×1000×1.25=5000ms, and the running time of TB-SCDM is 1000×1.25=1250ms.The execution time of total operations are as follows: the running time of Iqbal et al. [28] is 5×1000×1.25+1000×32.23=38480ms, the running time of Cui et al. [29] is 3×1000×1.25+2×1000×32.23=68210ms, the running time of Hong et al. [30] is 6×1000×1.25+2×1000×32.23=71960ms, the running time of Du et al. [31] is 8×1000×1.25=10000ms, and the running time of TB-SCDM is 3×1000×1.25=3750ms.On the whole, the computational efficiency of TB-SCDM is faster than the other four schemes [28–31]. In terms of security and algorithm efficiency, TB-SCDM is very suitable for secure communication in VANETs.


## 6.1. Benchmark Test of Blockchain

In order to efficiently perform operations, we accessed the data on TB-SCDM using the CRUD interface supplied by FISCO BCOS 2.0. The hardware environment is an Intel i5-8265U 1.80 GHz computer, 16 GB of memory, and running Windows 10 operating system.It is available to deploy several different nodes on the same server for a test chain, we used a Linux server to deploy six nodes. For the smart contract of the blockchain, we chose the solidity language. This paper adopts Caliper as the test script to test the smart contract of consortium blockchain. The consortium blockchain is composed of a single group of six nodes. We select the scenario of 10000 concurrent transactions and 1000 new user registrations. The performance objects tested include memory usage, CPU usage, data traffic, disk read and write volume of each node, etc.The performance metrics of send rate, latency, and throughput are described in Table2. Figure 5 shows the memory usage of each node when processing data. Figure 6 shows the CPU usage of each node when verifying information. Figure 7 shows the traffic required for each node to form a consensus. Figure 8 shows the amount of traffic required by each node to form a consensus on the hard disk.Table 2
The performance metrics of send rate, latency, and throughput.
NameSuccFailSend rate (TPS)Max latency(s)Min latency(s)Avg latency(s)Throughput (TPS)User10000606.22.160.321.52371.6Transfer100000976.618.351.3312.25509.7Figure 5
Memory usage of each node.Figure 6
CPU usage of each node.Figure 7
Traffic required for each node.Figure 8
Disc read and write amount of each node.


## 6.2. Benchmark Test of Signcryption

The TB-SCDM and previous schemes [28–31] are exploited by the jPBC library on a laptop, where the configuration is a Windows 11 operating system, 2.60 GHz Intel(R) Core(TM) i7-9750H CPU with 16-GB RAM.The meaning of the operation symbols is described in Table3. The performance comparison of different schemes is described in Table 4.Table 3
Symbols and descriptions of various operational times.
SymbolsMeaningOMThe time of a multiplication operation, 1OM≈1.25msOPThe time of a bilinear pairing operations, 1OP≈32.23msTable 4
Performance comparison with other schemes.
SchemesSigncryption costUnsigncryption costExecutiontime/n=1000ConfidentialityUnforgeabilityIqbal et al. [28]4nOMnOM+nOP5nOM+nOP/71980ms√√Cui et al. [29]nOP2nOM+2nOP3nOM+2nOP/166090ms√√Hong et al. [30]n3OM+OPn3OM+OP6nOM+2nOP/8820ms√√Du et al. [31]4nOM4nOM8nOM/8820ms√√TB-SCDM2nOMnOM3nOM/2520ms√√A simple and intuitive method can be adopted in order to estimate the computation efficiency of the computational of several schemes. In terms of overall cryptographic operations, we can find that Iqbal et al. [28] is 5nOM+nOP, Cui et al. [29] is 3nOM+2nOP, Hong et al. [30] is 6nOM+2nOP, Du et al. [31] is 8nOM, and TB-SCDM is 3nOM. From the perspective of formula, the cost efficiency of TB-SCDM is the highest.Figures9 and 10 describe the execution time of different schemes when n changes from 100 to 1000. From the perspective of change range, it can be seen that when the number of users gradually increases, the computational efficiency of TB-SCDM is more obvious than other schemes.Figure 9
Comparison of signcryption cost.Figure 10
Comparison of unsigncryption cost.In Figure11, in order to compare various schemes more clearly, we specially select the execution time of signcryption, unsigncryption, and total operations when the number of users n equals 1000. The execution times of signcryption operations are as follows: the running time of Iqbal et al. [28] is 4×1000×1.25=5000ms, the running time of Cui et al. [29] is 1000×32.23=32230ms, the running time of Hong et al. [30] is 1000×3×1.25+1000×32.23=35980ms, the running time of Du et al. [31] is 4×1000×1.25=5000ms, and the running time of TB-SCDM is 2×1000×1.25=2500ms.Figure 11
Comparison of total time (n=1000).The execution times of unsigncryption operations are as follows: the running time of Iqbal et al. [28] is 1000×1.25+1000×32.23=33480 ms, the running time of Cui et al. [29] is 2×1000×1.25+2×1000×32.23=66960ms, the running time of Hong et al. [30] is 1000×3×1.25+1000×32.23=35980ms, the running time of Du et al. [31] is 4×1000×1.25=5000ms, and the running time of TB-SCDM is 1000×1.25=1250ms.The execution time of total operations are as follows: the running time of Iqbal et al. [28] is 5×1000×1.25+1000×32.23=38480ms, the running time of Cui et al. [29] is 3×1000×1.25+2×1000×32.23=68210ms, the running time of Hong et al. [30] is 6×1000×1.25+2×1000×32.23=71960ms, the running time of Du et al. [31] is 8×1000×1.25=10000ms, and the running time of TB-SCDM is 3×1000×1.25=3750ms.On the whole, the computational efficiency of TB-SCDM is faster than the other four schemes [28–31]. In terms of security and algorithm efficiency, TB-SCDM is very suitable for secure communication in VANETs.


## 7. Summary

In VANETs, SV using automatic driving need to access each other or RSU, GPS and other nodes to obtain reliable and stable data transmission services. Because VANET uses wireless communication, its openness allows attackers to easily obtain communication signals and further forge user nodes or Internet of Things nodes, which poses a greater security threat to SV. Based on the above reasons, this paper proposes a new trusted blockchain-based signaling protocol and data management for authentication and authorization. This scheme can effectively reduce the storage space occupied by information and the cost of signcryption verification.



---

*Source: 9572992-2022-05-21.xml*