A secure and revocable data sharing method for Internet of Vehicles based on blockchain

Abstract

The present invention discloses a secure and revocable data sharing method for Internet of Vehicles based on blockchain, including system initialization for completing the initialization of related entities; registration of vehicles, roadside units and edge servers; edge servers signing broadcast messages; roadside units aggregating signatures of multiple edge servers to generate aggregate signatures; vehicles verifying signatures; and blockchain tracking malicious signers. The present invention uses a threshold signature algorithm and a non-interactive zero-knowledge proof method to encrypt messages broadcast by edge servers, effectively protecting the privacy of broadcast data; and also uses blockchain technology to effectively manage malicious signers. The present invention can realize secure and revocable data sharing in the Internet of Vehicles, and promotes the widespread application of the Internet of Vehicles.

Description

Technical Field

[0001] The present invention relates to Internet of Vehicles and blockchain technology, and in particular to a secure and revocable data sharing method for Internet of Vehicles based on blockchain. Background Art

[0002] The rapid development of information technology has paved the way for a new paradigm of service-oriented applications in in-vehicle networks. In in-vehicle networks, vehicles within the network download application services, including navigation maps, voice broadcasts, and entertainment content, from application service providers (ASPs) to improve the driving experience. However, accessing data directly from ASPs poses significant challenges to delay-sensitive applications and computationally intensive tasks in vehicle networks. Adopting this approach not only results in a large consumption of broadband resources and puts tremendous pressure on network infrastructure, but also causes considerable delays in the communication process. In addition, when vehicles submit a large number of service requests, this may overwhelm the ASP and cause its performance bottleneck.

[0003] To address the limitations associated with vehicles obtaining service data directly from ASPs, researchers propose caching ASP service content to an edge server (ES) close to the vehicle. As a result, vehicles can access service content directly from the ES, alleviating bandwidth pressure on data centers and enhancing the service experience for drivers and passengers. In addition, in in-vehicle networks, vehicles in the same area often request similar content, making caching commonly used service content in the ES an attractive option, particularly for location-based services and applications.

[0004] Although caching content in ES has significant advantages and potential, implementing such an architecture requires addressing various challenges. One of the most critical issues is ensuring effective security and privacy protection when vehicles obtain cached content from ES. 1) Since vehicle and ES communications are exposed to insecure wireless networks, they are vulnerable to various network attacks, such as simulation, replay, and collusion attacks. Therefore, it is crucial to establish a secure channel between ES and vehicles. 2) ES can provide multiple application services to vehicles at the same time, thereby improving the overall driving experience. However, the computing performance of vehicles is limited, and verifying multiple messages at the same time brings performance challenges. Therefore, it is crucial to aggregate ES broadcast messages or improve the efficiency of vehicle verification. 3) The high mobility of vehicles leads to unstable network connections, which affects the efficiency of ES services. Therefore, it is crucial to establish an effective network connection and authentication mechanism between vehicles and ES. In addition to solving communication security, another key issue lies in the response mechanism of ES, which provides corresponding service content according to vehicle requests. In existing studies, ES broadcasts messages as a fully trusted entity. However, ES may be compromised by attackers, resulting in tampering of service content and traffic interruption. Therefore, ensuring the reliability and traceability of ES broadcast messages remains challenging.

[0005] Several cryptography-based research schemes have been proposed to address the communication security problem. However, these schemes all have certain limitations and deficiencies and need further improvement. 1) Existing solutions use remote authentication servers to assist in secure communication between vehicles and ES. However, the interaction between multiple parties leads to greater authentication and communication delays. In addition, the increasing number of service requests can easily cause performance bottlenecks in the remote authentication server, affecting service quality and efficiency. 2) To improve the efficiency of message verification, some schemes use aggregate signatures to aggregate messages broadcast by ES. However, ES may collude with aggregators (i.e., roadside units (RSUs) or traffic center servers) to send false information and disrupt traffic. 3) To achieve fast authentication between vehicles and ES, existing schemes delegate the authentication function to ES. These schemes use encryption based on ciphertext policy attributes to establish fast connections between ES and vehicles, as well as access control of ES. However, the computational cost of this scheme varies with the attribute set and is not suitable for vehicles with limited computing resources.

[0006] To address the latter problem, related schemes have been proposed to use threshold signatures to enhance the reliability of ES broadcast messages. However, it is challenging to achieve message reliability using traditional threshold signatures. This difficulty stems from the inability to establish credible supervision over malicious signers, malicious aggregators, and publishers of false information. Some researchers believe that blockchain is a promising solution due to its decentralization, immutability, and credibility. This is because public information managed by blockchain smart contracts can achieve efficient authentication and revocation (i.e., deletion of public information). In addition, transactions executed in smart contracts are irreversible and traceable. However, although there are schemes that use blockchain to enhance vehicle communication security and ensure the dissemination of credible announcements, the problem of tracking malicious behavior during communication has not been considered. Summary of the invention

[0007] Purpose of the invention: The purpose of the present invention is to solve the deficiencies in the prior art and provide a secure and revocable data sharing method for Internet of Vehicles based on blockchain.

[0008] Technical solution: A secure and revocable data sharing method for Internet of Vehicles based on blockchain of the present invention comprises the following steps:

[0009] Step (1), system initialization, to achieve the initialization of vehicles, roadside units and edge servers; vehicles, roadside units and edge servers complete registration in the system, and the trusted center TA calculates the private key sk of the edge server i and public key pk i , the trusted center TA generates the corresponding identity vid for the vehicle i , Private Key and Certificate The trusted center TA provides the combined key sk for the roadside unit and the blockchain respectively a g={pk,sk rs ,t,ω} and the tracking key sk t ={pk,sk e ,t};

[0010] Step (2), the edge server generates a signature σ for the roadside unit i , the edge server signs the broadcast message m;

[0011] Step (3), the roadside unit receives the signature σ from the edge server i Then perform the aggregate signature, that is, the roadside unit aggregates the signatures of multiple edge servers to generate an aggregate signature σ; the specific method is:

[0012] Step (3-1), the roadside unit receives the signature σ from the edge server i , then the roadside unit obtains R from each edge server participating in the current signing process i , and calculate R = ∏ i∈C R i , z = ∑ i∈C z i , c = H(pk,R,m), and check whether g z =[∏ i∈C pk i ] c R is the signature information obtained by the edge server, R represents the signature calculated by Ri, R i represents the signature generated by each edge server, and z refers to the signature generated by z i The calculated signature;

[0013] Step (3-2), the roadside unit uses the ElGamal encryption algorithm to encrypt z, and randomly selects Calculate ct 1 =g ρ and The RSU randomly selects (b 1 ,…,b n )∈{0,1} n , if i = C, calculate where b i =1, C is the set of edge servers participating in the signature; the roadside unit generates a zero-knowledge proof Used to prove that R and the encrypted z are valid; the roadside unit uses the private key sk rs Signature (sk rs ,(m,R,ct 1 ,ct 2,ψ)) is used to generate tg; tg refers to the signature generated by the roadside unit using the aggregate key;

[0014] Step (3-3), the roadside unit sends an aggregate signature σ = {R, ct 1 ,ct 2 ,π,tg,TS exp} to the vehicle, where TS exp is a timestamp. Due to the characteristics of zero-knowledge proof, the adversary cannot obtain the ciphertext ct 1 and ct 2 Link to z;

[0015] Step (4): The vehicle performs signature verification on the aggregate signature σ sent by the roadside unit RSU. If the verification is successful, the message m is received. If the verification fails, the message is rejected and reported to the blockchain to assist in identifying and tracking the signing member responsible for the message.

[0016] Step (5): The blockchain tracks the malicious signer and revokes the malicious signer.

[0017] Furthermore, the specific content of the initialization of the vehicle, roadside unit and edge server in step (1) is as follows: the trusted center TA generates an elliptic curve E:y 2 =x 3 +ax+b modp, then TA selects generator P to generate elliptic curve group G of order q; the trusted center TA randomly selects two generators g and h; the trusted center TA selects a one-way hash function

[0018] The specific registration methods for vehicles, roadside units and edge servers are:

[0019] First, the trusted center TA randomly selects a private key based on the number of edge servers n. Calculate the corresponding public key That is, the public and private key pair pk of the edge server is formed * ={pk 1 ,…,pk n}、sk={sk 1 ,…,sk n}, i refers to the i-th edge server among n edge servers, i∈[1,…,n];

[0020] Then, the trusted center TA uses the ElGamal encryption algorithm to encrypt t and randomly selects Calculate T 0 =g ω ,T 1 =g t h ω , and TA provides a randomly generated private key And calculate the corresponding public key and TA generation (sk TA ,vk TA ) is used for signing and verification, where vk TA is publicly known; during this period, the trusted center TA assigns a unique identity vid to the legitimate vehicle i , and randomly generate a private key Calculate the corresponding public key Additionally, TA generates a unique certificate for the vehicle For identity verification;

[0021] Finally, TA sends pk={pk * ,pk t ,pk rs ,vk TA ,T 0 ,T 1}and Used for vehicle verification; the trusted center TA provides the combined key sk for the roadside unit and the blockchain respectively a g={pk,sk rs ,t,ω} and the tracking key sk t ={pk,sk e ,t}.

[0022] Furthermore, the specific method of generating a signature for the roadside unit RSU by the edge server in step (2) is as follows: In order to improve the reliability of the message m, multiple edge servers coordinate the message m broadcasted by the head edge server, and the edge server randomly selects And calculate c i =H(pk,R i ,m) and z i =r i +sk i ·c i ; Finally, the edge server sends the signature σ i =(R i ,z i ) to the roadside unit for generating the aggregate signature.

[0023] Furthermore, the detailed process of the vehicle verifying the aggregate signature σ sent by the roadside unit RSU in step (4) is as follows:

[0024] Step (4-1), in order to determine whether the message is a new message, the vehicle evaluates the equation TS c ≤TS exp Is it true, where TS cIndicates the timestamp when the message is received. If the inequality does not hold, the vehicle discards the message. If the inequality holds, the vehicle verifies the legitimacy of the signature and the consistency of the required message.

[0025] Step (4-2), through the public key pk = {pk * ,pk t ,pk rs ,T 0 ,T 1} Calculate c = H (pk, R, m), if the vehicle uses the Schnorr verification algorithm Verify (pk rs ,(m,R,ct,π),tg)=1 to complete the verification of the signature, ct={ct 1 ,ct 2};

[0026] Next, the vehicle determines whether the following equations are all true:

[0027]

[0028] ct 1 =g ρ ;

[0029]

[0030] T 0 =g λ ;

[0031]

[0032] v 0 =g η ;

[0033]

[0034] b i (1-b i )=0, (For example, b i ∈{0,1});

[0035] If the above equations are all true, it means that the message m is legal and correct, and the vehicle is allowed to receive the message. Here g z , g ρ , g λ 、h λ , g η , These are all intermediate calculations.

[0036] Furthermore, the specific process of the blockchain tracking signature in step (5) is as follows:

[0037] The blockchain receives the vehicle’s service request message Then, the blockchain uses the signature verification algorithm Verify the legality of the vehicle. After successful verification, the judgment equation is Is it true, where TS B Indicates the timestamp when the blockchain receives the message. If the timestamp is not within the validity period, the blockchain will disconnect the connection. Otherwise, to determine the legitimacy of (m,σ), the blockchain uses the Schnorr signature verification algorithm. If the verification fails, the blockchain outputs an error and returns the information to the vehicle.

[0038] If the above verification is successful, the blockchain retrieves {R,ct 1 ,ct 2 ,π,tg};

[0039] Then, the blockchain calculates the signature c = H (pk, R, m) and randomly selects Decrypt {ct using ElGamal algorithm 1 ,ct 2}, and calculate

[0040] Next, the blockchain looks for Calculate the public key pk C =∏ i∈C pk i , where the size of C is equal to t, the blockchain calculates and verifies whether the equality holds true; if the equation does not hold, the blockchain discards the connection and returns a failure to the vehicle, otherwise, the blockchain sends C to the vehicle and records the signer in set C in the blockchain.

[0041] Beneficial effects: To reduce the frequent occurrence of traffic jams and traffic accidents, in the technical solution of the present invention, the edge server uses non-interactive zero-knowledge signatures to encrypt traffic information, and then sends the encrypted information to the vehicle; the vehicle decrypts the received ciphertext and only needs to interact with the edge server once to obtain the necessary data, which improves the efficiency of the present invention. For malicious signers, the present invention uses blockchain to implement a tracking mechanism for malicious signers, which improves the practicality of the present invention.

[0042] Compared with the prior art, the present invention has the following advantages:

[0043] (1) The present invention uses threshold signature to sign the data broadcast by ES, and uses RSU to generate the corresponding aggregate signature. At the same time, considering the existence of malicious signers, the present invention combines blockchain to implement a tracking mechanism for malicious signers. In addition, the present invention avoids relying on the assumption that ES is completely trustworthy.

[0044] (2) The present invention realizes efficient and fast authentication between the vehicle and the ES based on the non-interactive knowledge signature scheme of the Σ protocol. In addition, the present invention uses the Fiat-Shamir transformation to realize the non-interactive Σ protocol, thereby improving the efficiency of vehicle authentication. Moreover, the entire authentication process does not require the participation of the remote authentication server.

[0045] The present invention realizes more functional features, such as supporting mutual authentication, obtaining content directly from edge servers, supporting signer tracking, etc. In addition, the security of the cryptographic protocol is evaluated through formal security analysis and can resist multiple types of attacks, which is more secure than other related schemes. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 It is a schematic diagram of the overall system framework of the present invention;

[0047] Figure 2 A comparison chart of computational overhead for signature generation in an embodiment of the present invention;

[0048] Figure 3 This is a comparison chart of signature verification computation overhead in an embodiment of the present invention. DETAILED DESCRIPTION

[0049] The technical solution of the present invention is described in detail below, but the protection scope of the present invention is not limited to the embodiments.

[0050] like Figure 1As shown, the secure and revocable data sharing method of the Internet of Vehicles based on blockchain of the present invention involves participating entities, namely, a trusted center (TA), a blockchain, an edge server (ES), a roadside unit (RSU) and a vehicle. The communication modes of the present invention include V2T, V2V, V2R and V2B. V2T is used for offline / online registration of vehicles / RSU / ES / and encryption materials. V2V is used for inter-vehicle communication through a dedicated short-range communication protocol. V2R refers to the communication between the vehicle and the RSU or ES to obtain traffic information such as navigation and road conditions. V2B is used for vehicles to request blockchain assistance to track malicious message signers or share ES traffic status. In addition, the trusted center TA assumes the responsibilities of a system administrator, is responsible for creating system parameters, and is also responsible for generating corresponding encryption materials for entities, deploying smart contracts, and facilitating secure communications. Each vehicle has an on-board device that can safely and reliably perform encryption and decryption processes. The vehicle also needs to confirm whether the requested message is correct and whether the aggregate signature is legal. ES is installed on both sides of the road and uses cloud server providers to cache applications and traffic-related data. For vehicle inquiries, ES is responsible for issuing a list of service types and delivering relevant information. To enhance the credibility of messages, multiple ES independently sign messages. RSU is a wireless infrastructure located beside the road. Its main task is to provide network connection, forward service information, and provide various services to vehicles. Each RSU controls multiple ES and is responsible for aggregating the signatures generated by ES. Blockchain is a decentralized ledger maintained by fully trusted base stations. It is responsible for storing private keys that track signatures. Blockchain securely manages transactions between multiple consensus nodes and maintains the status of smart contracts through consensus algorithms.

[0051] The secure and revocable data sharing method of the Internet of Vehicles based on blockchain in this embodiment includes the following steps:

[0052] Step (1), system initialization, to achieve the initialization of vehicles, roadside units and edge servers; vehicles, roadside units and edge servers complete registration in the system, and the trusted center TA calculates the private key sk of the edge server i and public key pk i , the trusted center TA generates the corresponding identity vid for the vehicle i , Private Key and Certificate The trusted center TA provides the combined key sk for the roadside unit and the blockchain respectively a g={pk,sk rs ,t,ω} and the tracking key sk t ={pk,sk e ,t};

[0053] Step (2), the edge server generates a signature σ for the roadside unit i, the edge server signs the broadcast message m;

[0054] Step (3), the roadside unit receives the signature σ from the edge server i Then perform the aggregate signature, that is, the roadside unit aggregates the signatures of multiple edge servers to generate an aggregate signature σ; the specific method is:

[0055] Step (3-1), the roadside unit receives the signature σ from the edge server i , then the roadside unit obtains R from each edge server participating in the current signing process i , and calculate R = ∏ i∈C R i , z = ∑ i∈C z i , c = H(pk,R,m), and check whether g z =[∏ i∈C pk i ] c R receives the signature information from the edge server.

[0056] Step (3-2), the roadside unit uses the ElGamal encryption algorithm to encrypt z, and randomly selects Calculate ct 1 =g ρ and The RSU randomly selects (b 1 ,…,b n )∈{0,1} n , if i = C, calculate where b i =1, C is the set of edge servers participating in the signature; the roadside unit generates a zero-knowledge proof Used to prove that R and the encrypted z are valid; the roadside unit uses the private key sk rs Signature (sk rs ,(m,R,ct 1 ,ct 2 ,ψ)) is used to generate tg;

[0057] Step (3-3), the roadside unit sends an aggregate signature σ = {R, ct 1 ,ct 2 ,π,tg,TS exp} to the vehicle, where TS exp is a timestamp. Due to the characteristics of zero-knowledge proof, the adversary cannot obtain the ciphertext ct 1 and ct 2 Link to z;

[0058] Step (4): The vehicle performs signature verification on the aggregate signature σ sent by the roadside unit RSU. If the verification is successful, the message m is received. If the verification fails, the message is rejected and reported to the blockchain to assist in identifying and tracking the signing member responsible for the message.

[0059] Step (5), blockchain tracks malicious signers.

[0060] The specific contents of the initialization of the vehicle, roadside unit and edge server in step (1) are as follows: the trusted center TA generates an elliptic curve E:y 2 =x 3 +ax+b modp, then TA selects generator P to generate elliptic curve group G of order q; the trusted center TA randomly selects two generators g and h; the trusted center TA selects a one-way hash function

[0061] The specific registration methods for vehicles, roadside units and edge servers are:

[0062] First, the trusted center TA randomly selects a private key based on the number of edge servers n. Calculate the corresponding public key That is, the public and private key pair pk of the edge server is formed * ={pk 1 ,…,pk n}、sk={sk 1 ,…,sk n}, i refers to the i-th edge server among n edge servers, i∈[1,…,n];

[0063] Then, the trusted center TA uses the ElGamal encryption algorithm to encrypt t and randomly selects Calculate T 0 =g ω ,T 1 =g t h ω , and TA provides a randomly generated private key And calculate the corresponding public key and TA generation (sk TA ,vk TA ) is used for signing and verification, where vk TA is publicly known; during this period, the trusted center TA assigns a unique identity vid to the legitimate vehicle i , and randomly generate a private key Calculate the corresponding public key Additionally, TA generates a unique certificate for the vehicle For identity verification;

[0064] Finally, TA sends pk={pk * ,pk t ,pk rs ,vk TA ,T 0 ,T 1}and Used for vehicle verification; the trusted center TA provides the combined key sk for the roadside unit and the blockchain respectively a g={pk,sk rs ,t,ω} and the tracking key sk t ={pk,sk e ,t}.

[0065] In step (2) of this embodiment, the edge server generates a specific method for the roadside unit RSU: multiple edge servers cooperate with the message m broadcast by the head edge server, and the head edge server randomly selects And calculate c i =H(pk,R i ,m) and z i =r i +sk i ·c i ; Finally, the edge server sends the signature σ i =(R i ,z i ) to the roadside unit for generating the aggregate signature.

[0066] The detailed process of the vehicle verifying the aggregate signature σ sent by the roadside unit RSU in step (4) of this embodiment is as follows:

[0067] Step (4-1), vehicle evaluation equation TS c ≤TS exp Is it true, where TS c Indicates the timestamp when the message is received. If the inequality does not hold, the vehicle discards the message. If the inequality holds, the vehicle verifies the legitimacy of the signature and the consistency of the required message.

[0068] Step (4-2), through the public key pk = {pk * ,pk t ,pk rs ,T 0 ,T 1} Calculate c = H (pk, R, m), if the vehicle uses the Schnorr verification algorithm Verify (pk rs ,(m,R,ct,π),tg)=1 completes the verification of the signature;

[0069] Next, the vehicle determines whether the following equations are all true:

[0070]

[0071] ct 1 =g ρ ;

[0072]

[0073] T 0 =g λ ;

[0074]

[0075] v 0 =g η ;

[0076]

[0077] b i (1-b i )=0;

[0078] If the above equations are all true, it means that the message m is legal and correct, and the vehicle is allowed to receive the message.

[0079] The specific process of blockchain tracking signature in step (5) of this embodiment is as follows:

[0080] The blockchain receives the vehicle’s service request message Then, the blockchain uses the signature verification algorithm Verify the legality of the vehicle. After successful verification, the judgment equation is Is it true, where TS B Indicates the timestamp when the blockchain receives the message. If the timestamp is not within the validity period, the blockchain will disconnect the connection. Otherwise, to determine the legitimacy of (m,σ), the blockchain uses the Schnorr signature verification algorithm. If the verification fails, the blockchain outputs an error and returns the information to the vehicle.

[0081] If the above verification is successful, the blockchain retrieves {R,ct 1 ,ct 2 ,π,tg};

[0082] Then, the blockchain calculates the signature c = H (pk, R, m) and randomly selects Decrypt {ct using ElGamal algorithm 1 ,ct 2}, and calculate

[0083] Next, the blockchain looks for Calculate the public key pk C =∏i∈C pk i , where the size of C is equal to t, the blockchain calculates and verifies whether the equality holds true; if the equation does not hold, the blockchain discards the connection and returns a failure to the vehicle, otherwise, the blockchain sends C to the vehicle and records the signer in set C in the blockchain.

[0084] Example:

[0085] In order to present a more complex and practical threshold signature environment, this embodiment sets n to 1.5t, and the value of the threshold t varies from 2 to 20. In order to intuitively compare the results, the actual application signature generation calculation overhead of the technical solution of the present invention is compared with the calculation overhead of other solutions. The results are as follows: Figure 2 As shown, when the threshold t=20, the total computational overhead is reduced by approximately (4744.46-603.522) / 4744.46=87.28%, (3879.45-603.522) / 3879.45=84.4%, (9571.89-603.522) / 9571.89=93.69%, and (10278.4-603.522) / 10278.4=94.13% respectively compared with the total computational overhead of the existing scheme.

[0086] The computational overhead of signature verification in actual application of the technical solution of the present invention is compared with the computational overhead of other existing solutions. The results are as follows: Figure 3 As shown. Since the signature verification of the present invention is performed by the vehicle, the technical solution of the present invention exhibits lower computational overhead compared to the technical solution of Li et al. Specifically, when the threshold t=20, the computational overhead reduced by the technical solution of the present invention is approximately (5809.35-3859.76) / 5809.35=33.56%.

[0087] In addition, in the technical solution of the present invention, the total overhead of signature generation and signature verification is compared with related solutions. The present invention has lower computational overhead, and the overall computational cost is reduced by approximately 17.92%, 53.51%, 53.93%, and 56.62%, respectively.

Claims

1. A secure and revocable data sharing method for Internet of Vehicles based on blockchain, characterized by: The following steps are involved: Step (1), system initialization, initialization of vehicles, roadside units and edge servers; The vehicle, roadside unit and edge server complete the registration in the system, and the trusted center TA calculates the private key sk of the edge server i and public key pk i , the trusted center TA generates the corresponding identity vid for the vehicle i , Private Key and Certificate The trusted center TA provides the combined key sk for the roadside unit and the blockchain respectively a g={pk,sk rs ,t,ω} and the tracking key sk t ={pk,sk e ,t}; t represents the threshold number; Step (2), the edge server generates a signature σ for the roadside unit i , the edge server signs the broadcast message m; the specific method of the step (2) that the edge server generates a signature for the roadside unit RSU: multiple edge servers cooperate with the message m broadcast by the head edge server, and the head edge server randomly selects And calculate c i =H(pk,R i ,m) and z i =r i +sk i ·c i ; Finally, the edge server sends the signature σ i =(R i ,z i ) to the roadside unit for generating an aggregate signature; Step (3), the roadside unit receives the signature σ from the edge server i Then perform the aggregate signature, that is, the roadside unit aggregates the signatures of multiple edge servers to generate an aggregate signature σ; the specific method is: Step (3-1), the roadside unit receives the signature σ from the edge server i , then the roadside unit obtains R from each edge server participating in the current signing process i , and calculate R = ∏ i∈C R i , z = ∑ i∈C z i , c = H(pk,R,m), and check whether g z =[∏ i∈C pk i ] c R is the signature information obtained by the edge server; R represents the signature calculated by Ri, R i represents the signature generated by each edge server, and z refers to the signature generated by z i The calculated signature; Step (3-2), the roadside unit uses the ElGamal encryption algorithm to encrypt z, and randomly selects Calculate ct1 = g ρ and The RSU randomly selects (b1,…,b n )∈{0,1} n , if i = C, calculate where b i =1, C is the set of edge servers participating in the signature; the roadside unit generates a zero-knowledge proof Used to prove that R and the encrypted z are valid; the roadside unit uses the private key sk rs Signature (sk rs ,(m,R,ct1,ct2,ψ)) is used to generate tg; tg refers to the signature generated by the roadside unit using the aggregate key; Step (3-3), the roadside unit sends an aggregate signature σ = {R, ct1, ct2, π, tg, TS exp } to the vehicle, where TS exp is a timestamp. Due to the characteristics of zero-knowledge proof, the adversary cannot link to z through the ciphertexts ct1 and ct2; Step (4), the vehicle performs a signature verification on the aggregate signature σ sent by the roadside unit RSU. If the verification is successful, the message m is received. If the verification fails, the message is rejected and reported to the blockchain to assist in identifying and tracking the signing member responsible for the message. The detailed process is: Step (4-1), vehicle evaluation equation TS c ≤TS exp Is it true, where TS c Indicates the timestamp when the vehicle receives the message, TS exp Represents the timestamp when the roadside unit sends the message. If the inequality does not hold, the vehicle discards the message. If the inequality holds, the vehicle verifies the legitimacy of the signature and the consistency of the required message. Step (4-2), through the public key pk = {pk * ,pk t ,pk rs ,T0,T1} calculate c=H(pk,R,m), if the vehicle uses the Schnorr verification algorithm Verify(pk rs ,(m,R,ct,π),tg)=1 to complete the verification of the signature, ct={ct1,ct2}; Next, the vehicle determines whether the following equations are all true: ct1=g ρ ; T0=g λ ; v0=g η ; b i (1-b i )=0; If the above equations are all true, it means that the message m is legal and correct, and the vehicle is allowed to receive the message; Step (5): The blockchain tracks the malicious signer and revokes the malicious signer. The specific process of blockchain tracking signatures is as follows: The blockchain receives the vehicle’s service request message Then, the blockchain uses the signature verification algorithm Verify the legality of the vehicle. After successful verification, the judgment equation is Is it true, where TS B Indicates the timestamp when the blockchain receives the message. If the timestamp is not within the validity period, the blockchain will disconnect the connection. Otherwise, to determine the legitimacy of (m,σ), the blockchain uses the Schnorr signature verification algorithm. If the verification fails, the blockchain outputs an error and returns the information to the vehicle. If the above verification is successful, the blockchain retrieves {R,ct1,ct2,π,tg} based on the vehicle’s request information; Then, the blockchain calculates the signature c = H (pk, R, m) and randomly selects Decrypt {ct1, ct2} using the ElGamal algorithm and calculate Next, the blockchain looks for Calculate the public key pk C =∏ i∈C pk i , where the size of C is equal to t, the blockchain calculates and verifies whether the equality If the equation does not hold, the blockchain discards the connection and returns a failure to the vehicle. Otherwise, the blockchain sends C to the vehicle and records the signer in the set C in the blockchain. The specific content of the initialization of the vehicle, roadside unit and edge server in step (1) is as follows: the trusted center TA generates an elliptic curve E:y 2 =x 3 +ax+b modp, then TA selects generator P to generate elliptic curve group G of order q; the trusted center TA randomly selects two generators g and h; the trusted center TA selects a one-way hash function The specific registration methods for vehicles, roadside units and edge servers are: First, the trusted center TA randomly selects a private key based on the number of edge servers n. Calculate the corresponding public key That is, the public and private key pair pk of the edge server is formed * ={pk1,…,pk n }、sk={sk1,…,sk n }, i refers to the i-th edge server among n edge servers, i∈[1,…,n]; Then, the trusted center TA uses the ElGamal encryption algorithm to encrypt t and randomly selects Calculate T0 = g ω ,T1=g t h ω , and TA provides a randomly generated private key And calculate the corresponding public key and TA generation (sk TA ,vk TA ) is used for signing and verification, during which the trusted center TA assigns a unique identity vid to the legitimate vehicle i , and randomly generate a private key Calculate the corresponding public key TA generates a unique certificate for the vehicle For identity verification; Finally, TA sends pk={pk * ,pk t ,pk rs ,vk TA ,T0,T1} and Used for vehicle verification; the trusted center TA provides the combined key sk for the roadside unit and the blockchain respectively a g={pk,sk rs ,t,ω} and the tracking key sk t ={pk,sk e ,t}.

Images