Efficient message verification method for Internet of Vehicles based on improved BLS algorithm

Abstract

The invention provides an Internet of Vehicles efficient message verification method based on an improved BLS algorithm, and belongs to the technical field of Internet of Vehicles security. The technical problems that under the verification architecture based on a traditional BLS algorithm, when the Internet of Vehicles cope with large-scale message authentication, resource overhead is large, certificate management is complex, and safety is insufficient are solved. According to the technical scheme, the method comprises the following steps that S1, a system is initialized; s2, the vehicle performs single message signature and broadcasts the single message signature to the road side unit and other vehicles; s3, the receiver performs integrity and authenticity verification on the received single message; and S4, if a large number of signature messages are received, the vehicle or the road side unit aggregates the signature messages and performs batch verification. According to the invention, low overhead and high safety are realized, and malicious vehicle tracing is supported.

Description

Technical Field

[0001] This invention relates to the field of vehicle network security technology, and in particular to an efficient message verification method for vehicle networks based on an improved BLS algorithm. Background Technology

[0002] The Internet of Vehicles (IoV), a product of the deep integration of the automotive industry and information technology, enables intelligent information interaction and sharing among people, vehicles, roads, and the cloud by incorporating advanced onboard sensors, controllers, and communication equipment. It excels in improving traffic efficiency, reducing traffic accidents, and optimizing the driving experience. From a technical perspective, it encompasses both wide-area communication technologies, such as cellular networks, and short-range direct communication technologies between vehicles (V2V) and between vehicles and infrastructure (V2I), forming a multi-mode collaborative information dissemination system. Among these, the Dedicated Short Range Communication (DSRC) protocol, as a core technology of vehicle-road cooperation, utilizes the 5.9GHz frequency band to achieve low-latency, highly reliable data transmission between vehicles and infrastructure, providing crucial communication support for safety applications such as emergency braking alerts and intersection traffic warnings.

[0003] However, with the large-scale application of vehicle-to-everything (V2X) technology in public transportation, intelligent road networks, and autonomous driving, the volume and sensitivity of vehicle dynamic information and user privacy data transmitted by the DSRC protocol have significantly increased. This has led to a multi-dimensional expansion of security challenges in message transmission, encompassing data confidentiality, transmission integrity, and message authentication validity. Regarding message authentication, because the protocol is based on an open access mechanism via wireless channels and lacks a dynamic identity update mechanism, attackers can use forged On-Board Unit (OBU) identities to send malicious commands, such as forging emergency braking signals, triggering chain-reaction rear-end collisions. In terms of data integrity, the DSRC protocol uses a default CRC check mechanism, which is vulnerable to sophisticated man-in-the-middle attacks. Attackers can disrupt traffic flow by modifying traffic signal commands or forging road construction warnings. These proactive security attacks targeting vehicles not only threaten the safety of individual vehicles but may also trigger systemic security crises through the network propagation characteristics of V2X.

[0004] To ensure the authenticity and integrity of message transmission in Vehicle-to-Everything (V2X) networks while balancing privacy protection and behavioral traceability, researchers have conducted extensive studies. Early message authentication schemes based on Public Key Infrastructure (PKI) verified authenticity by attaching certificates to signed messages. However, the increased computational overhead and complex management of certificates make them unsuitable for resource-constrained and real-time-critical V2X scenarios. To address this issue, the paper "Identity-based cryptosystems and signature schemes" proposed an identity-based message authentication method that directly generates public keys using vehicle identifiers and other identity information, eliminating the need for certificate verification. However, existing identity-based schemes in V2X networks suffer from key escrow defects. For example, node private keys rely on a trusted authority for computation and distribution, making the authority a single point of failure. Furthermore, the control over private key generation by a central institution can easily lead to abuse of privileges, identity theft, and the theft of driving privacy, severely limiting their application in V2X security scenarios.

[0005] To address the efficiency and security issues of certificate management and key escrow, researchers have proposed numerous certificateless authentication schemes. Elliptic curve cryptography (ECC), with its low computational complexity and small key size, has become a key technology for optimizing certificateless schemes. For example, the paper "privacy-preserving mutual authentication scheme for group communication in VANET" implements bidirectional group authentication for multiple vehicles, using a pseudonym mechanism to protect privacy and reduce latency, but it is limited by pseudonym storage and key management in large-scale scenarios. The scheme proposed in the paper "Pairing-free certificateless aggregate signcryptionscheme for vehicular sensor networks" claims to have confidentiality and authentication functions, but has been proven to have security vulnerabilities and is susceptible to signature forgery attacks. Bilinear pairing technology also has unique advantages in aggregate signature verification. For example, the BLS signature aggregation scheme proposed in the paper "Aggregate and verifiably encrypted signatures from bilinear maps" can avoid rogue-key attacks, but the verification overhead increases linearly with the number of messages (verifying n messages requires n pairing operations), which severely restricts efficiency in computing-constrained scenarios. The aggregatable BLS scheme proposed in the subsequent paper "Compact multi-signatures for smaller blockchains" achieves a constant-size aggregated public key, but the key aggregation process requires high-cost scalar multiplication, which greatly increases the computational burden of the system.

[0006] Meanwhile, the demand for multi-signature compression and privacy protection has driven the rapid development of homomorphic encryption technology in certificate-free schemes. For example, the HAS scheme proposed in the paper "A homomorphic aggregate signature scheme based on lattice" can achieve multi-user heterogeneous signature compression; the scheme proposed in the paper "Improved Homomorphic Encryption with Optimal Key Generation Technique for VANETs" improves privacy protection and computational performance by optimizing the key generation process; and the scheme in the paper "Homomorphic encryption and federated learning-based privacy-preserving CNN training: Covid-19 detection use-case" combined with BFV encryption reduces the risk of data leakage. However, all three are difficult to adapt to latency-sensitive scenarios due to high computational costs, complex key management, and insufficient technological maturity. Furthermore, research in group signatures and batch verification focuses on balancing anonymity and verification efficiency: the paper "IBRS: an efficient identity-based batch verification scheme for VANETs based on ring signature" integrates identity-based cryptography with ring signature technology to achieve conditional privacy protection. Although the batch verification efficiency is high, the cost of single-message verification is high due to the need to perform pairing operations. The paper "Traceable identity-based group signature" integrates group signatures and identity-based cryptography. Although it reduces storage overhead and certificate management costs, its application scenarios are limited due to the risk of key escrow and the lack of a private key revocation mechanism.

[0007] In summary, while existing vehicle-to-everything (V2X) message authentication schemes have achieved breakthroughs in specific technical fields, they generally suffer from deficiencies in security, computational overhead, or scenario adaptability. Furthermore, the highly dynamic topology and low-latency requirements of V2X pose even greater challenges to authentication schemes in terms of efficiency and reliability (encompassing message source verification and integrity protection).

[0008] To clearly explain the principles and steps of this invention, relevant cryptographic knowledge will be explained first:

[0009] 1. BLS (Boneh–Lynn–Shacham) signature algorithm:

[0010] (1) Formal definition of BLS algorithm

[0011] System initialization (Setup): Input the security parameter λ, generate the bilinear group parameters: (G1, G2, G... T The hash function H:{0,1}*→G2, where G1,G2,G T Let G1 be a multiplicative cyclic group of order p, g1 and g2 be generators of group G1 and G2 respectively, and e be a non-degenerate bilinear mapping. The final output params = {p, G1, G2, G...} T ,g1,g2,e,H}.

[0012] Key generation (KeyGen): Input params, randomly select a private key sk←Z p * Calculate the public key pk = sk·g1, and output the public-private key pair (sk, pk).

[0013] Signature generation (Sign): Input private key sk and target message m∈{0,1}*, hash the message to group element h=H(m)∈G2, calculate signature σ=sk·h∈G2, and output signature σ.

[0014] Signature Verification: Input public key pk, message m and signature σ, output Boolean value: calculate hash value h = H(m) ∈ G2, verify bilinear mapping equation: e(σ, g1) = e(h, pk). If the equation is true, output 1, otherwise output 0.

[0015] (2) Improved Algorithm Analysis

[0016] Traditional BLS signature verification relies on a single public-private key pair (sk,pk) to perform bilinear pairing e(σ,g1)=e(h,pk) calculation. While this can be adapted to aggregated message verification scenarios, in single message authentication, the high computational complexity of bilinear pairing will significantly increase the operating cost of terminals such as vehicle OBUs, resulting in low efficiency. Summary of the Invention

[0017] This invention provides an efficient message verification method for vehicle-to-everything (V2X) networks based on an improved BLS algorithm. Addressing the technical problems of high resource overhead, complex certificate management, and insufficient security in large-scale message authentication in V2X networks, this invention utilizes an improved BLS signature algorithm combined with bilinear mapping technology within the V2X architecture to achieve efficient verification of both single and aggregated messages. This significantly reduces computational overhead while also providing effective privacy protection for vehicles.

[0018] For ease of understanding, the symbols and their meanings involved in this invention are first given in Table 1 below:

[0019] Table 1. Symbols and their meanings

[0020]

[0021]

[0022] This invention is achieved through the following measures: an efficient message verification method for vehicle-to-everything (V2X) networks based on an improved BLS algorithm, comprising the following steps:

[0023] S1, System initialization;

[0024] S2. The vehicle signs the message and broadcasts it to the roadside unit and other vehicles;

[0025] S3. The receiver verifies the integrity and authenticity of each received message.

[0026] S4. If a large number of signature messages are received, the vehicle or roadside unit aggregates them and performs batch verification.

[0027] Further, step S1 includes:

[0028] S11. The Trusted Authority (TA) initializes system parameters;

[0029] S111, The center of trust (TA) is chosen from the cyclic groups G1, G2, G... of the elliptic curve of order p. T Where p is a large prime number, Z p * Let G1 and G2 be integer multiplication groups modulo p, with generators g1 and g2 respectively. Input a security parameter λ and select a random number d∈Z. p * As the system private key, calculate the system public key P = d·g1;

[0030] S112. The Trusted Center (TA) selects two one-way collision-resistant hash functions H:{0,1}. * →G1,H DLEQ :{0,1}*→Z p * The system parameters {p,g1,g2,H,H} are published. DLEQ ,G1,G2,G T ,P};

[0031] S12. The Trusted Center (TA) registers the vehicle entity and distributes public and private keys to the vehicle. The vehicle uses its private key to generate a pseudonym for communication.

[0032] S121, Trusted Center TA is for vehicle V i Generate a unique identity ID i That is, the true identity of the vehicle, and select a random number sk∈Z. p* As vehicle V i The private key is used to calculate the public key pk. i,1 =sk·g1,pk i,2 =sk·g2, the Trusted Center (TA) provides the vehicle V with a secure channel. i Distribute public and private key pairs;

[0033] S122, Vehicle V i Calculate the pseudonym PID using the private key sk i = H(sk||t')·g1, where t' is the timestamp, pseudonym PID i It will be updated regularly to protect privacy; the Trusted Center (TA) stores the V data for each vehicle. i Public key-pseudonym mapping table (pk i ,PID i ,t').

[0034] Further, step S2 includes:

[0035] S21, Vehicle V i After entering the communication domain of the roadside unit (RSU), the message m is first signed with a core signature: σ = sk·H(m); where sk is the vehicle V. i The private key σ is the core signature of the target message m;

[0036] S22, Vehicle V i Randomly select secret values ​​k∈Z p * And combining the system generator g1 and the message hash H(m), the auxiliary elements R1 and R2 are calculated: R1 = k·g1, R2 = k·H(m);

[0037] S23, Vehicle V i Generate challenge value c: c = H DLEQ (g1,m,pk i，1 ,σ,R1,R2,PID i ,t2), calculate s=kc·skmodp, where g1 is the system generator, m is the message to be signed, σ is the core signature, and sk is the vehicle V i The private key, R1 and R2 are auxiliary elements, PID i t2 is the vehicle's pseudonym, and t2 is the timestamp;

[0038] S24, Vehicle structure signature message M = {m, pk i，1 ,σ,PID i ,(c,s),t2} is sent to nearby roadside units (RSUs) or other vehicles;

[0039] Further, step S3 includes:

[0040] S31. The receiver uses the signed message to calculate the auxiliary element;

[0041] S311. The receiver checks the freshness of the message by verifying whether the timestamp t2 of the received message satisfies |T-t2|≤ΔT, where T is the receiver's current time and ΔT is the maximum allowed time deviation. If the condition is met, the authentication process continues.

[0042] S312: The receiver calculates auxiliary elements R1' and R2' using the signed message: R1' = s·g1 + c·pk i,1 R2' = s·H(m) + c·σ;

[0043] S32. The receiver uses the signed message and auxiliary elements to calculate the challenge value and verify the signature's validity.

[0044] S321. The receiver uses the signed message and auxiliary elements R1' and R2' to calculate the challenge value c': c' = H DLEQ (g1,m,pk i,1 ,σ,R1',R2',PID i ,t2);

[0045] S322. The receiver verifies whether the calculated challenge value c' is consistent with the received challenge value c. If they are consistent, the receiver accepts the signature; otherwise, the receiver rejects the signature.

[0046] S3221: First, calculate the auxiliary elements R1' and R2' using s = kc·sk, where k ∈ Z. p * c is the received challenge value, and sk is the vehicle V. i The private key is derived as follows:

[0047] R1'=s·g1+c·pk i,1

[0048] =(kc·sk)·g1+c·sk·g1

[0049] =k·g1-c·sk·g1+c·sk·g1

[0050] =k·g1

[0051] =R1

[0052] R2'=s·H(m)+c·σ

[0053] = (kc·sk)·H(m) + c·sk·H(m)

[0054] =k·H(m)-c·sk·H(m)+c·sk·H(m)

[0055] = k·H(m)

[0056] =R2

[0057] S3222: Since R1' = R1 and R2' = R2, it can be deduced that the challenge value c' is exactly the same as the input content of the hash operation in which c participates. Based on this, the following derivation can be made:

[0058] c' = H DLEQ (g1,m,pk i,1 ,σ,PID i ,R1',R2',t2)

[0059] =H DLEQ (g1,m,pk i,1 ,σ,PID i (R1,R2,t2)

[0060] =c

[0061] Further, step S4 includes:

[0062] S41. When n signed messages are received, the vehicle or roadside unit (RSU) aggregates them: asig = (asig[0], asig[1], asig[2]), where

[0063] S42. To ensure message integrity and reliability and improve verification efficiency, the receiver performs batch verification of aggregated messages.

[0064] S421: First, check the freshness of each message timestamp t2: |T1-t2|≤ΔT', where T1 is the receiver's current time and ΔT' is the maximum allowed time deviation. If it passes, continue the authentication process.

[0065] S422: If all signed messages come from the same vehicle, the receiver verifies them using the following equation: e(asig[0]+n·t·pk) i,1 ,g2)=e(H(m)+t.g1,n·pk i,2 ), t∈Z p *, e represents a bilinear mapping, n is the total number of signed messages, pk i,1 PK i,2 This is the public key of the vehicle user; The sum of all core signatures is used. If the equation holds true, the verification passes; otherwise, the verification fails, and the batch of signed messages is rejected. The derivation of the correctness of the verification equation is as follows:

[0066]

[0067] S423: If the signed messages come from different vehicles, the receiver verifies them using the following equation:

[0068] e(asig[0]+t·asig[2],g2)=e(H(m)+t.g1,asig[1]); t∈Z p *, e represents a bilinear mapping. The sum of all core signatures. PK for the vehicle's public key i,2 The sum of the sums, PK for the vehicle's public key i,1 The cumulative sum is used to verify the validity of the message signature. If the equation holds true, the verification passes; otherwise, the verification fails, and the batch of signed messages is rejected. The derivation of the correctness of the verification equation is as follows:

[0069] e(H(m)+t·g1,asig[1])

[0070] =e(H(m)+t·g1,pk 1,2 +pk 2,2 +pk 3,2 +...+pk n,2 )

[0071] =e(H(m)+t·g1,sk1·g2+sk2·g2+sk3·g2+...+sk n ·g2)

[0072] =e(H(m)·(sk1+sk2+sk3+...+sk n )·g2)+e(t·g1·(sk1+sk2+sk3+...+sk n )·g2)

[0073] =e((σ 1 +σ 2 +...+σ n )·g2)+e(t·(pk 1,1 +pk 2,1 +pk 3,1 +...+pk n,1 )·g2)

[0074] =e(asig[0]+t·asig[2],g2)

[0075] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0076] (1) Compared with the traditional BLS signature scheme, this method can ensure the integrity and reliability of the signature by simply performing basic hash and dot multiplication operations when verifying a single message, avoiding complex bilinear mapping operations and significantly improving the computational efficiency of vehicle nodes.

[0077] (2) In multi-message aggregation verification scenarios, this invention primarily employs public key summation operations, reducing bilinear mapping and dot product operations in traditional schemes. Theoretical analysis and experimental evaluation results show that this method has significant advantages in terms of computational and communication overhead while meeting security requirements, making it suitable for resource-constrained vehicle networking environments.

[0078] (3) Based on the random oracle model and the ROR (Real-Or-Random) model, this invention provides formal security proofs and combines informal security analysis to prove that the proposed method maintains computational efficiency while significantly improving security strength compared to existing methods. It can effectively resist typical attacks such as impersonation, replay and collusion, while satisfying message integrity, authentication and conditional anonymity, and supporting the trusted center to trace the identity of malicious vehicles. Attached Figure Description

[0079] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0080] Figure 1 The present invention provides an overall flowchart of an efficient message verification method for vehicle networking based on an improved BLS algorithm.

[0081] Figure 2 This is a diagram of the vehicle networking system architecture in this invention.

[0082] Figure 3 A comparison chart of the computational costs of single signature verification provided by this invention.

[0083] Figure 4 This invention provides a comparison chart of the computational overhead of the message authentication stage as the number of signatures increases.

[0084] Figure 5 A comparison chart of communication overhead for a single signature stage provided by the present invention.

[0085] Figure 6 This invention provides a comparison chart of communication overhead during the message authentication stage as the number of signatures increases. Detailed Implementation

[0086] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. Of course, the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0087] Example 1: This Example 1 provides an efficient message verification method for vehicle-to-everything (V2X) networks based on an improved BLS algorithm, such as... Figure 1As shown, it includes the following steps:

[0088] S1, System initialization;

[0089] S2. The vehicle signs the message and broadcasts it to the roadside unit and other vehicles;

[0090] S3. The receiver verifies the integrity and authenticity of each received message.

[0091] S4. If a large number of signature messages are received, the vehicle or roadside unit aggregates them and performs batch verification.

[0092] like Figure 2 As shown, the vehicle network architecture based on the improved BLS algorithm for efficient message authentication includes: a trusted authority (TA), a roadside unit (RSU), and an on-board unit (OBU).

[0093] (1) Trusted Center (TA): As a centralized and highly secure infrastructure in the system, the TA executes an improved key generation algorithm, is responsible for initializing system parameters, registers entities and issues public and private keys, stores relevant parameters for authenticating vehicle identities, and can trace illegal vehicle identities when malicious behavior occurs in the system.

[0094] (2) Roadside Unit (RSU): As a critical infrastructure deployed along the road, the RSU serves as the communication hub between the Trusted Controller (TA) and the On-Board Unit (OBU). It interacts with vehicles in real time via wireless channels and establishes a reliable connection with the TA via wired channels. Its main functions include vehicle authentication and dynamic pseudonym updates.

[0095] (3) On-board unit (OBU): The device installed inside the vehicle is the terminal device for the vehicle to access the Internet of Vehicles. It is a resource-constrained terminal and is responsible for wireless communication with the roadside unit (RSU) and other vehicles. It performs core functions such as improved signature generation algorithm, pseudonym management, and location information collection.

[0096] 1. Security Model

[0097] Random Oracle Model:

[0098] To ensure the security of this method during the rapid identity authentication phase, we use a random oracle model to complete a formal proof, guaranteeing the unforgeability of message authentication.

[0099] The security model of this scheme is defined by a game between a challenger and an attacker. If the probability of the attacker winning the game is negligible, then the message authentication scheme is said to be unforgeable under an adaptive message selection attack. An attacker can perform the following oracle query:

[0100] User-generated query: Adversary's identity (PID) i Challenger C queries the maintained list to find the identity. If the identity exists in the list, the challenger returns the user's public key to the adversary; if the identity does not exist in the list, the challenger randomly selects k. i ∈Z p * Calculate the corresponding public key pk i,1 And will be returned to the opponent A.

[0101] H(.) Query: Attacker A sends message m to challenger C to propose a hash query. C first checks list L. H If A contains the tuple (m, H(m)), return H(m) to A; otherwise, output H(x) ∈ Z via a random oracle. p *Returned to A as a response, and saved to table L with columns (x, H(x)). H middle;

[0102] User private key query: When challenger C receives the attacker's PID (User ID) query... i When requesting a private key, challenger C retrieves the private key response list L. sk If a corresponding tuple {PID} exists i ,pk i,1 If ,sk}, then return the result with respect to PID. i The associated user private key sk; if it does not exist, the challenger randomly selects sk∈Z. p * Calculate the corresponding public key and return sk to A;

[0103] H DLEQ Query: When challenger C receives the query tuple {m, pk} submitted by attacker A... i,1 ,σ,R1,R2,PID i When querying the pre-maintained hash query response list L, for each t2, g1}, the query is performed. DLEQ If the queried tuple matches an existing item in the list, C directly returns the corresponding challenge value c to C; if no matching item exists, challenger C randomly selects c∈Z. p *, add it to list L DLEQ In the middle, and return c to C;

[0104] Signature Query: Attacker A initiates a query targeting user PID i In the signature lookup on message m, challenger C identifies the PID based on the maintained list.i The message m is signed and returned to attacker A.

[0105] The game is specifically defined as follows:

[0106] Game 1: Challenger C and Attacker A play a game.

[0107] System initialization phase: Challenger C executes the system initialization program, inputs the security parameter λ, generates system public parameters and master key pair, sends the system public parameters and public key to attacker A, and keeps the private key secret;

[0108] Interrogation Phase: The attacker adaptively performs H(.) queries, user private key queries, and H... DLEQ Inquiry, signature required;

[0109] Forgery Phase: Finally, the attacker outputs the anonymous user's PID. i The signed message {m*,pk on message m* i,1 *,PID i *,σ*,(c*,s*),t2*}.

[0110] Attacker A wins the game if their output satisfies the following conditions:

[0111] 1) The signature message uses the public key pk i,1 *Anonymous user PID i A valid signature on message m;

[0112] 2) PID i *The user's private key was not submitted to the user for a private key query;

[0113] 3)(PID i *,m*) was never queried in the signature query.

[0114] Definition 1: If the probability of attacker A winning game 1 in polynomial time is negligible, then the probability of attacker successfully forging a signature in polynomial time is negligible. Therefore, this message authentication scheme is said to be unforgeable under adaptive selected message attack.

[0115] 2. Security Requirements

[0116] As an open and heterogeneous vehicle-to-everything (V2X) communication system, VANETs face complex scenarios involving highly dynamic nodes, open wireless channels, and multi-entity interactions. Its message authentication scheme must meet multiple security requirements, including message integrity and authentication, resistance to impersonation attacks, protection of identity privacy, traceability, and defense against various traditional attacks.

[0117] Message integrity and authentication: After receiving a signed message, the recipient can authenticate it to confirm the integrity and reliability of the message, that is, the message was sent by a legitimate user and has not been tampered with by a malicious user.

[0118] Anti-spoofing attack: Spoofing attacks refer to preventing unauthorized or fraudulent vehicles from entering the vehicle network system through identity verification.

[0119] Privacy of identity: The real identity of the message sender is anonymous during the communication process, and no third party can obtain the sender's real identity information from the anonymity.

[0120] Traceability: When there is a dispute over the source of information or when an accident occurs that requires holding someone accountable, the system can promptly trace and revoke the vehicle's true identity to prevent it from continuing to endanger system security.

[0121] Resisting various traditional attacks: Attackers cannot obtain relevant useful information to achieve their goals through certain traditional attacks, such as tampering attacks, replay attacks, and collusion attacks.

[0122] 3. Security Analysis

[0123] Correctness analysis:

[0124] Theorem 1 (Correctness) The scheme presented in this paper satisfies the correctness requirement.

[0125] Proving the correctness of a signature scheme involves verifying the correctness of the equations during the signature verification process. This section will analyze the correctness of the above scheme in both individual and batch verification.

[0126] 1. Correctness of single-message verification

[0127] When the signature message M is received, the verifier needs to check whether c and c' are equal. First, the auxiliary elements R1' and R2' are calculated using s = kc·sk. The specific derivation process is as follows:

[0128] R1'=s·g1+c·pk i,1

[0129] =(kc·sk)·g1+c·sk·g1

[0130] =k·g1-c·sk·g1+c·sk·g1

[0131] =k·g1

[0132] =R1

[0133] R2'=s·H(m)+c·σ

[0134] = (kc·sk)·H(m) + c·sk·H(m)

[0135] =k·H(m)-c·sk·H(m)+c·sk·H(m)

[0136] = k·H(m)

[0137] =R2

[0138] Since R1' = R1 and R2' = R2, it can be concluded that the challenge value c' is exactly the same as the input content of the hash operation in which c participates. Based on this, the following derivation can be made:

[0139] c' = H DLEQ (g1,m,pk i,1 ,σ,PID i ,R1',R2',t2)

[0140] =H DLEQ (g1,m,pk i,1 ,σ,PID i (R1,R2,t2)

[0141] =c

[0142] The above derivation proves the correctness of the single-message verification in this scheme.

[0143] 2. Batch verification of the correctness of aggregated messages

[0144] (1) When n messages M are received from the same vehicle i When i = 1, 2, 3...n, the verifier calculates whether the following equation holds true:

[0145] e(asig[0]+n·t·pk i,1 ,g2)=e(H(m)+t.g1,n·pk i,2 )

[0146] because The following derivation can then be performed:

[0147]

[0148] Therefore, in the process of batch verification of aggregated messages, if the above equation holds, the verifier can use this to determine whether n messages M from the same vehicle are valid. i (i = 1, 2, 3... n) Batch verification is correct.

[0149] (2) When n messages M from different vehicles are received i When i = 1, 2, 3...n, the verifier calculates whether the following equation holds true:

[0150] e(asig[0]+t·asig[2],g2)=e(H(m)+t.g1,asig[1])

[0151] because The following equation can be derived:

[0152] e(H(m)+t·g1,asig[1])

[0153] =e(H(m)+t·g1,pk 1,2 +pk 2,2 +pk 3,2 +...+pk n,2 )=e(H(m)+t·g1,sk1·g2+sk2·g2+sk3·g2+...+sk n ·g2)=e(H(m)·(sk1+sk2+sk3+...+sk n )·g2)+e(t·g1·(sk1+sk2+sk3+...+sk n )·g2)=e((σ 1 +σ 2 +...+σ n )·g2)+e(t·(pk 1,1 +pk 2,1 +pk 3,1 +...+pk n,1 )·g2)=e(asig[0]+t·asig[2],g2)

[0154] During the batch verification of aggregated messages, if the above equation holds true, the verifier can use this to determine the origin of n messages M from different vehicles. i The batch verification of (i = 1, 2, 3... n) is correct.

[0155] In summary, the analysis of the batch verification process of aggregated messages in scenarios involving the same vehicle and different vehicles fully demonstrates the correctness of the batch verification mechanism in this solution.

[0156] Formal security analysis:

[0157] Based on the definition of the security model, this section demonstrates the security of the proposed solution through a game between challenger C and attacker.

[0158] Theorem 1: Assuming the ECDLP problem holds, then under the random oracle model, this scheme is unforgeable under an adaptive choice message attack by attacker A, i.e., it is proven secure.

[0159] Proof: Suppose there exists a polynomial-time adversary who can forge message signature tuples M that satisfy the verification rules. C is a challenger capable of solving the ECDLP problem using attacker A. Given an instance of the ECDLP problem (g1, pk... i,1 =x·g1). C maintains a list for each random oracle, which is used to record the answers provided by A, L,L H , L sk ,L σ Record user-generated queries, pseudonym queries H, H DLEQ Hash query, private key query, and signature query.

[0160] Challenger C chooses PID i *As the target, and simulating a random oracle environment, play the following game against attacker A:

[0161] Initialization Phase: Challenger C executes the system initialization program, during which system parameters params = {p, g1, g2, H, H} are generated. DLEQ ,P} and send this parameter to attacker A.

[0162] Query phase: A interacts with C by performing queries on the following random oracles.

[0163] (1) User-generated: C creates a list L and initializes it to empty, with the storage format being a triplet {PID} i ,pk i,1 ,k i}, the adversary inputs their identity (PID) i When making a query, challenger C searches list L; if a corresponding item exists, it returns PK. i,1 Give opponent A; if not, the challenger randomly selects k. i ∈Z p *, calculate pk i,1 =k i ·g1, the challenger will {PID i ,pk i,1 ,k i Store the data in list L, and then store pk... i,1 Return it to opponent A.

[0164] (2)L H Question: C creates list L H It is initialized to empty and stored in the form of a tuple (m, H(m)). When challenger C receives a query for message m, if list L... H If a tuple (m, H(m)) exists in L, then C returns the corresponding H(m) to A; otherwise, C randomly selects H(m) ∈ G1* and adds (m, H(m)) to L.H In the middle, H(m) is returned to A.

[0165] (3)H DLEQ Question: C creates list H DLEQ It is initialized to empty and stored in the form of a tuple {(m, pk)}. i,1 ,σ,R1,R2,PID i When challenger C receives {m,pk} from A, t2,g1),c} i,1 ,σ,R1,R2,PID i When querying ,t2,g1}, if list L DLEQ It contains tuples (m, pk) i,1 ,σ,R1,R2,PID i If the expression is: t2, g1, c), then C will return c to A; otherwise, C will randomly select c ∈ Z. p *, then (m,pk i,1 ,σ,R1,R2,PID i ,t2,c) Add to list L DLEQ In the middle, and return c to C.

[0166] (4) Private key query: C creates list L sk It is initialized to empty and stored in a triplet format: {PID} i ,pk i,1 When challenger C receives information from attacker A regarding the PID, i When querying the private key, if the PID i =PID i *Then stop querying. If PID i ≠PID i * Challenger C query list L pk Does {PID} already exist in the database? i ,pk i,1 If sk ∈ Z exists, challenger C responds with sk to attacker A; otherwise, challenger C randomly selects sk ∈ Z. p * Calculate the corresponding pk i,1 =sk·g1, the challenger will {PID i ,pk i,1 ,sk} store in L sk Then return sk to A.

[0167] (5) Signature lookup: When challenger C receives a signature from A for {m, PID} i When querying the signature of t2}: if PID i =PID i *, C terminates the game; otherwise, challenger C leaves L. sk Extract the private key sk, and randomly select k∈Zp * Calculate the corresponding R1 = k·g1; from L H Extract the corresponding H(m), calculate R² = k·H(m); call H DLEQ Query to obtain the challenge value c, calculate s = kc·skmodp, and then set {m,PID i Store ,t2,σ,R1,R2,(c,s)} into L σ Returns the signature message {m.pk i,1 ,PID i Let ,σ,(c,s),t2} be given to attacker A.

[0168] Forgery Phase: Assume that after attacker A completes the above query, A outputs a forged signature σ*=(c*,s*,R1*,R2*) corresponding to message m*. Therefore, the following equation can be determined to hold:

[0169] R1'=s*·g1+c*·pk i,1 R2'=s*·H(m*)+c*·σ*

[0170] If the signature forgery is successful, since R1* and R1' are equal, we have R1* = k·g1 and R1' = s*·g1 + c*·pk. i,1 We can obtain,

[0171] k = s* + x·c*

[0172] If c* ≠ 0, then x = (ks*)·c* -1

[0173] Challenger output x = (ks*)·c* -1 As a solution to the ECDLP problem, the proposed solution is unforgeable under an adaptive choice message attack by attacker A, as the ECDLP problem is difficult to solve.

[0174] As can be seen from Theorem 1, an adversary cannot forge the signature specified by the challenger's anonymous identity in probabilistic multinomial time based on the message transmitted through the public channel. Therefore, the proposed scheme is unforgeable under adaptive chosen message attack.

[0175] Informal security analysis:

[0176] Theorem 1: This embodiment can achieve non-forgeability.

[0177] The security of this signature scheme is proven to be based on a formal security framework for digital signatures under the random oracle model. In the scheme construction, the signature generation process can be formally represented as σ←sign(sk,H(m)), where sk∈Z. q *Let H:{0,1}*→G1 be the signature private key, and H:{0,1}*→G1 be the cryptographic hash function. According to the rigorous proof of Theorem 1, under the random oracle model assumption, an attacker cannot deduce the private key sk from the known signature and public key. In summary, the scheme proposed in this invention satisfies the unforgeability requirement. Q.E.D.

[0178] Theorem 2: This embodiment can achieve indistinguishability.

[0179] The proof demonstrates that since the hash value H(m) of each message is modeled as an idealized random function, the output of the signature component σ = sk·H(m) exhibits complete unpredictability and a uniform distribution, making signatures generated by different private keys indistinguishable in terms of distribution. Furthermore, since the private key sk is combined with the hash value through a single operation, attackers cannot reverse-engineer sk from the signature result, preventing them from inferring the differences between different private keys based on the correlation between signatures. Therefore, this scheme achieves indistinguishability. Q.E.D.

[0180] Theorem 3: This embodiment can achieve resistance to replay attacks.

[0181] This proof demonstrates that in this scheme, the timestamp t2 is used during the signature generation phase to ensure the freshness of each signature. Therefore, when verifying a signature, the verifier must first check the timestamp t2 to ensure that each signature is the latest message. If the timestamp expires, the verifier will reject the message, which effectively prevents replay attacks. Therefore, this scheme satisfies resistance to replay attacks. Q.E.D.

[0182] Theorem 4: This embodiment can achieve resistance to collusion attacks.

[0183] This embodiment demonstrates that the signature process involves combining a hash function H. DLEQ Generate challenge value c: c = H DLEQ (g1,m,pk i，1 ,σ,R1,R2,PID i The response value s = kc·sk is strongly bound to the vehicle private key sk, the challenge value c, and the random secret value k. If a conspirator wants to forge a signature, they need to overcome the computational difficulty of elliptic curve discrete logarithms and construct a signature satisfying c' = c without knowing sk. This is computationally infeasible, thus ensuring the signature's unforgeability and resisting signature forgery attacks by conspirators. Therefore, the present invention can resist conspiratorial attacks. Q.E.D.

[0184] Theorem 5 states that this embodiment can achieve conditional privacy protection.

[0185] This proves that during normal communication, vehicles communicate anonymously via PID. i=H(sk||t')·g1, the attacker cannot extract the vehicle's true identity from the anonymity. However, the attacker saves the (pk) of each vehicle during vehicle registration. i ,PID i The mapping table (t') is used. Therefore, when a vehicle is identified as malicious and its true identity needs to be traced, the TA can use the pseudonym PID. i Find the corresponding public key pk using the timestamp t'. i This allows for the determination of the vehicle's true identity. In conclusion, this solution achieves conditional privacy protection. Q.E.D.

[0186] Theorem 5 states that this embodiment can achieve resistance to spoofing attacks.

[0187] Prove that in order to successfully launch a spoofing attack, the attacker must generate an expression that satisfies the equation: c = H DLEQ (g1,m,pk i,1 ,σ,R1,R2,PID i ,t2)=c'=H DLEQ (g1,m,pk i,1 ,σ,R1',R2',PID i The signature message {m,pk) of t2) i，1 ,σ,PID i However, under the ECDLP assumption, this operation is impossible. Therefore, the proposed solution is resistant to spoofing attacks.

[0188] Example 2: To verify the performance of the present invention, Example 2 compares and analyzes it with three representative existing vehicle-to-everything (V2X) message authentication schemes, including Scheme 1 proposed by Imam et al. in "Efficient lightweight anonymous authentication scheme with certificateless aggregation for VANETs", Scheme 2 proposed by Imghoure et al. in "Schnorr-based conditional privacy-preserving authentication scheme with multisignature and batch verification in VANET", and Scheme 3 proposed by Wu et al. in "A security-enhanced certificateless aggregatesigncryption scheme for vehicular ad hoc networks". Since the above schemes are highly consistent with the present method in terms of application background and security objectives for message authentication, they are highly comparable.

[0189] 1. Performance Analysis

[0190] (1) Computational cost analysis

[0191] To compare the computational overhead of the proposed scheme with existing schemes, the execution time of various operations in the scheme was first evaluated experimentally. The experiment was implemented in a C / C++ environment using a precise integer arithmetic library and a pairwise cryptography (PBC) library. The experimental hardware platform was configured with an Intel I7-7500U processor (2.7GHz) and 8GB of memory, running Ubuntu 16.04. To reduce single-sample measurement error, each encryption operation was executed independently 1000 times, and the final experimental results are expressed as the arithmetic mean. In the subsequent comparative analysis, given that operations such as XOR, addition, and subtraction have extremely short execution times and their computational overhead has a negligible impact on overall performance, these low-overhead operations were not included in the statistical scope. The symbolic representation and execution time of various operations are shown in Table 2 below.

[0192] Table 2. Various operations and their execution times

[0193]

[0194]

[0195] In Scheme 1, the verification process for a single signature requires four elliptic curve scalar multiplication operations and two elliptic curve point addition operations. Based on this, the computational cost of verifying a single signature can be estimated to be 4T. s +2T a =1.4018; When verifying n signatures, this scheme requires performing 2n+1 elliptic curve scalar multiplication operations and 3n-1 elliptic curve point addition operations, and its computational cost for signature verification is (2n+1)T. s +(3n-1)T a .

[0196] In Scheme 2, a single signature verification requires four elliptic curve scalar multiplication operations and one elliptic curve point addition operation, therefore its computational cost for a single signature verification is 4T. s +T a =1.3999; In a scenario with n signature verifications, this scheme requires 2n+2 elliptic curve scalar multiplications and n+1 elliptic curve point additions, with a corresponding computational cost of (2n+2)T. s +(n+1)T a .

[0197] For Scheme 3, a single signature verification process requires 4 elliptic curve scalar multiplication operations and 3 elliptic curve point addition operations, resulting in a computational cost of 4T for a single signature verification. s +3T a =1.4037; When verifying n signatures, 3n+2 elliptic curve scalar multiplication operations and 5n elliptic curve point addition operations are required. The computational cost of verifying n signatures is (3n+2)T. s +5nT a .

[0198] The proposed scheme in this embodiment requires four elliptic curve cryptography scalar multiplication operations and two elliptic curve point addition operations in the single signature verification stage, resulting in a computational overhead of 3T for a single signature verification. s +2T a =1.0523; In the aggregate signature verification (i.e., batch message verification) stage, n+1 elliptic curve cryptography scalar multiplication operations, 2 bilinear mapping operations, and 2 elliptic curve dot addition operations need to be performed. Therefore, the computational cost of batch message verification in this scheme is (n+1)T. s +2T b +2T a .

[0199] The computational costs of each scheme are compared in Table 3.

[0200] Table 3 Comparison of computational costs

[0201]

[0202] In comparison, the proposed scheme significantly reduces computational overhead in both the single-message verification and aggregated signature verification stages. In the single-message verification stage, compared to Schemes 1, 2, and 3, the overhead is reduced by 33.21%, 33.03%, and 33.39%, respectively. As the number of signatures increases, the computational cost advantage of this scheme amplifies significantly. When the message size reaches n=400 (details of the improved signature verification efficiency are shown in Table 6), its computational overhead is reduced by 89%, 88%, and 184% compared to Schemes 1, 2, and 3, respectively. A comparison of the computational cost of this embodiment with other comparative schemes in the single-signature verification stage is shown below. Figure 3 As shown, the computational overhead of this embodiment compared with other comparative schemes under different numbers of vehicles is as follows: Figure 4 As shown in the figure, the advantages of the message authentication mechanism in this scheme become more apparent as the number of verified vehicles increases. Therefore, by utilizing the improved BLS signature algorithm, this embodiment achieves higher authentication efficiency and security, reduces computational burden, and meets the low computational overhead requirements in the vehicle-to-everything (V2X) environment.

[0203] (2) Communication overhead analysis

[0204] We compare and analyze the communication overhead generated by schemes 1 to 3 during message signature transmission, where Z is defined as... p The storage space for * is 20 bytes; the storage space for elements in an elliptic curve group is 40 bytes; the storage space for elements in a finite field-based group is 128 bytes; the storage space for plaintext messages in VANETs is 67 bytes; and the storage space for timestamps is 4 bytes.

[0205] The specific storage space distribution of various data elements in different schemes is shown in Table 4.

[0206] Table 4. Space occupied by different types of elements

[0207]

[0208] In Scheme 1, the signature message format during V2V or V2I communication is {pid}. i ,m i ,σ i ,pk i ,T i ,ΔT i}, σ i =(X i ,δ i ), where pid i ∈Z p *, T i ,ΔT i ∈T, Xi ,pk i ∈G,δ i ∈G'. The total communication overhead is 128 + 2*40 + 67 + 20 + 2*4 = 303 bytes.

[0209] In Scheme 2, the signature message format in the V2V or V2I communication process is {m i ,PID i PoP i ,t i ,pk i ,(R i ,s i )}, PID i =(PID i,1 ,PID i,2 ,T i ), where PID i,1 ,pk i ,R i ∈G, PID i,2 PoP i ,s i ∈Z p *, t i ,T i ∈T. The total communication overhead is 3*40+3*20+67+2*4=255 bytes.

[0210] In Scheme 3, the signature message format for vehicle broadcasts is as follows: σi=(U i ,z i ,w i ID i =(ID) i,1 ID i,2 ), U i ,XID i YID i ID i,1 ∈G, z i ID i,2 ∈Z p *, t i ∈T, w i For ∈G', the total communication overhead is 4*40+128+2*20+4=332 bytes.

[0211] In this embodiment, the signature message format for vehicle broadcasting is {m,pk} i，1 ,σ,PID i ,(c,s),t2}, where pk i,1 ,PID i ∈G, σ,c,s∈Z p*, t2∈T. The length of a single message signature is calculated as follows: 2*40+67+3*20+4=211 bytes, and the total communication overhead is 211 bytes.

[0212] As can be seen from the above analysis, there are significant differences in the number of communication overheads in different schemes. In order to clarify the differences in communication costs between the schemes, the communication overhead of this embodiment and schemes 1-3 are compared and calculated for "single signature sending stage" and "n signature sending stages", respectively. The comparison data is shown in Table 5.

[0213] Table 5 Comparison of Communication Overhead

[0214]

[0215] In comparison, the proposed solution significantly reduces communication overhead. During the single-message verification phase, it reduces overhead by 44%, 21%, and 57% compared to solutions 1, 2, and 3, respectively. As the number of signatures increases, the communication cost of this embodiment compared to other comparative solutions in the single-signature phase is... Figure 5 As shown, the communication cost of the aggregate signature stage is as follows: Figure 6 As shown in the figure, the authentication scheme proposed in this invention has significant advantages in different communication scenarios: when the signature size increases linearly from 1 to n, the communication overhead growth rate of this scheme is significantly lower than that of schemes 1-3. This characteristic ensures that even if the number of messages the system needs to process increases significantly, the network resource consumption will not increase proportionally, but rather exhibits a slow upward trend. Therefore, by utilizing the improved BLS signature algorithm, this embodiment achieves lower communication overhead and higher protocol execution efficiency, and can better adapt to high-density, dynamically changing network environments such as vehicular ad hoc networks.

[0216] 2. Security Analysis

[0217] We conducted a comparative safety analysis of the proposed solution and solutions 1-3. "√" indicates that the solution possesses the corresponding safety attributes, while "×" indicates that the solution cannot meet the safety requirements or has not considered them. As shown in Table 6 below, the proposed solution has a significant advantage in safety compared to the comparative solutions.

[0218] Table 6 Security Analysis

[0219]

[0220]

[0221] As shown in Table 6, Schemes 1 and 3 do not consider the security requirements of countering collusion attacks and non-connectivity; Scheme 2 does not analyze the security requirements of countering spoofing attacks and collusion attacks. Compared with other schemes, this scheme, in addition to meeting basic security requirements such as message authentication, privacy protection, traceability, and resistance to replay attacks, also possesses security features such as resistance to collusion attacks, non-connectivity, and spoofing attacks, ensuring more comprehensive security. In summary, this embodiment is superior to existing schemes in terms of security and can meet the high security and high flexibility requirements of the vehicle network environment.

[0222] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A high-efficiency message verification method for vehicle-to-everything (V2X) networks based on an improved BLS algorithm, characterized in that, Includes the following steps: S1, System initialization; S2. The vehicle signs the message and broadcasts it to the roadside unit and other vehicles; S3. The receiver verifies the integrity and authenticity of each received message. S4. If a large number of signature messages are received, the vehicle or roadside unit aggregates them and performs batch verification.

2. The efficient message verification method for vehicle-to-everything (V2X) networks based on the improved BLS algorithm according to claim 1, characterized in that, Step S1 includes the following steps: S11. Trusted Center (TA) initializes system parameters; S12. The Trusted Center (TA) registers the vehicle entity and distributes public and private keys to the vehicle. The vehicle uses its private key to generate a pseudonym for communication. In step S11, the Trusted Center (TA) initializes system parameters, which includes the following steps: S111, The center of trust (TA) is chosen from the cyclic groups G1, G2, G... of the elliptic curve of order p. T Where p is a large prime number, Z p * Let G1 and G2 be integer multiplication groups modulo p, with generators g1 and g2 respectively. Input a security parameter λ and select a random number d∈Z. p * As the system private key, calculate the system public key P = d·g1; S112. The Trusted Center (TA) selects two one-way collision-resistant hash functions H:{0,1}. * →G1,H DLEQ :{0,1}*→Z p * The system parameters {p,g1,g2,H,H} are published. DLEQ ,G1,G2,G T ,P}; In step S12, the Trusted Center (TA) implements monitoring of vehicle V. i Entity registration and vehicle V i Distribute public and private keys, and the vehicle uses its private key to generate a pseudonym for communication, including the following steps: S121, Trusted Center TA is for vehicle V i Generate a unique identity ID i That is, the true identity of the vehicle, and select a random number sk∈Z. p * As vehicle V i The private key is used to calculate the public key pk. i,1 =sk·g1,pk i,2 =sk·g2, the Trusted Center (TA) provides the vehicle V with a secure channel. i Distribute public and private key pairs; S122, Vehicle V i Calculate the pseudonym PID using the private key sk i = H(sk||t')·g1, where t' is the timestamp, pseudonym PID i It will be updated regularly to protect privacy; the Trusted Center (TA) stores the V data for each vehicle. i Public key-pseudonym mapping table (pk i ,PID i ,t').

3. The efficient message verification method for vehicle-to-everything (V2X) networks based on the improved BLS algorithm according to claim 1, characterized in that, Step S2 includes the following steps: S21, Vehicle V i After entering the communication domain of the roadside unit (RSU), the message m is first signed with a core signature: σ = sk·H(m); where sk is the vehicle V. i The private key σ is the core signature of the target message m; S22, Vehicle V i Randomly select secret values ​​k∈Z p * And combining the system generator g1 and the message hash H(m), the auxiliary elements R1 and R2 are calculated: R1 = k·g1, R2 = k·H(m); S23, Vehicle V i Generate challenge value c: c = H DLEQ (g1,m,pk i，1 ,σ,R1,R2,PID i ,t2), calculate s=kc·skmodp, where g1 is the system generator, m is the message to be signed, σ is the core signature, R1, R2 are auxiliary elements, and PID i t2 is the vehicle's pseudonym, and t2 is the timestamp; S24, Vehicle structure signature message M = {m, pk i，1 ,σ,PID i ,(c,s),t2} is sent to nearby roadside units (RSUs) or other vehicles.

4. The efficient message verification method for vehicle-to-everything (V2X) networks based on the improved BLS algorithm according to claim 1, characterized in that, Step S3 includes the following steps: S31. The receiver uses the signed message to calculate the auxiliary element; S32. The receiver uses the signed message and auxiliary elements to calculate the challenge value and verify the signature's validity. In step S31, the receiver checks the calculation auxiliary elements through the following steps: S311. The receiver checks the freshness of the message by verifying whether the timestamp t2 of the received message satisfies |T-t2|≤ΔT, where T is the receiver's current time and ΔT is the maximum allowed time deviation. If the condition is met, the authentication process continues. S312. The receiver calculates auxiliary elements R1' and R2' through the signed message: R1' = s·g1 + c·pk i,1 , R2'=s·H(m)+c·σ; In step S32, the receiver calculates the challenge value and verifies the signature's validity through the following steps: S321. The receiver uses the signed message and auxiliary elements R1' and R2' to calculate the challenge value c': c' = H DLEQ (g1,m,pk i,1 ,σ,R1',R2',PID i ,t2); S322. The receiver verifies whether the calculated challenge value c' is consistent with the received challenge value c. If they are consistent, the receiver accepts the signature; otherwise, the receiver rejects the signature.

5. The efficient message verification method for vehicle-to-everything (V2X) networks based on the improved BLS algorithm according to claim 1, characterized in that, Step S4 includes the following steps: S41. When n signed messages are received, the vehicle or roadside unit (RSU) aggregates them: asig = (asig[0], asig[1], asig[2]), where S42. The receiver performs batch verification of the aggregated messages; In step S42, the process of the receiver performing batch verification of the aggregated messages includes the following steps: S421: First, check the freshness of each message timestamp t2: |T1-t2|≤ΔT', where T1 is the receiver's current time and ΔT' is the maximum allowed time deviation. If it passes, continue the authentication process. S422: If all signed messages come from the same vehicle, the receiver verifies them using the following equation: e(asig[0]+n·t·pk) i,1 ,g2)=e(H(m)+t.g1,n·pk i,2 ), t∈Z p *, e represents a bilinear mapping, n is the total number of signed messages, pk i,1 PK i,2 This is the public key of the vehicle user; The sum of all core signatures is calculated. If the equation is true, the verification passes; otherwise, the verification fails and the batch of signed messages is rejected. S423: If the signed messages come from different vehicles, the receiver verifies them using the following equation: e(asig[0]+t·asig[2],g2)=e(H(m)+t.g1,asig[1]); t∈Z p *, e represents a bilinear mapping. The sum of all core signatures. PK for the vehicle's public key i,2 The sum of the sums, PK for the vehicle's public key i,1 If the sum of the values ​​is true, the verification passes; otherwise, the verification fails and the batch of signed messages is rejected.

Images