Efficient aggregation anonymous verification method for vehicular ad hoc networks and related devices

Abstract

The embodiment of the application discloses a kind of vehicle ad hoc network efficient aggregation anonymous verification method and related device, the method is verified based on the freshness of time stamp first, guarantee the freshness of time stamp from source;Then the validity of single signature is verified one by one, eliminate received invalid signature;Finally, aggregate signature verification is carried out, and the overall validity of all signatures can be verified by once bilinear pairing operation, compared with the verification of traditional method one by one, multiple bilinear pairing operations are needed, and the calculation complexity can be reduced.In high concurrency scene, processing delay is shortened from seconds to hundreds of milliseconds, which can effectively solve the problem of low efficiency of dynamic message authentication in Internet of Things, especially in vehicle networking, and meet the real-time demand.In addition, the application also introduces the smart contract and distributed digital identity verification technology of block chain, which can prevent malicious attacks of Internet of Things virus or node, and it is particularly important to improve privacy protection and prevent privacy leakage.

Description

Technical Field

[0001] This invention relates to the field of secure communication technology for vehicle networks, and in particular to a method and device for efficient aggregation and anonymous verification of vehicle self-organizing networks. Background Technology

[0002] With the development of the Internet of Things (IoT), especially the rapid popularization of intelligent connected vehicle technology, vehicle-to-everything (V2X) has become a core support for intelligent transportation systems. It enables real-time interaction between vehicles, roadside units, pedestrians, and the cloud, achieving traffic information sharing, collaborative decision-making, and safety warnings. However, the openness, dynamism, and real-time nature of V2X communication present serious security challenges: vehicle nodes need to rapidly exchange critical information such as location, speed, and braking status in high-speed moving scenarios; any tampering, forgery, or delay in messages could trigger a chain of traffic accidents (such as rear-end collisions or running red lights). Simultaneously, the anonymity and mobility of vehicle nodes require communication to balance privacy protection and identity traceability, preventing unauthorized tracking of user trajectories or malicious nodes masquerading as legitimate nodes for long-term malicious activities.

[0003] V2X involves multiple vehicles, each broadcasting its signature to a Roadside Unit (RSU). Traditional signature verification methods verify vehicle signatures one by one through the RSUs. With n signatures, n bilinear pairing operations are required for verification, resulting in low efficiency. Therefore, improving the efficiency of signature verification to meet the real-time requirements of the Internet of Things (IoT), especially in vehicle-to-everything (V2X) networks, preventing malicious attacks from IoT viruses, and enhancing privacy protection and preventing privacy leaks are crucial. Summary of the Invention

[0004] This application provides a method and apparatus for efficient aggregation and anonymous verification of vehicle ad hoc networks, which helps to improve verification efficiency.

[0005] The first aspect of this application provides a method for efficient aggregation and anonymous verification in vehicle ad hoc networks, applied to roadside units, the method comprising:

[0006] Receive a signature tuple, pseudonym and timestamp broadcast by the vehicle node, wherein the signature tuple includes multiple signatures, and each signature includes a pair of temporary public keys and a signature component;

[0007] Upon confirming the validity of the timestamp, for each signature, a new second hash value is calculated based on the temporary public key, the message to be signed, and the roadside unit public key; a first element is calculated based on the signature component and the generator; and a second element is calculated based on the temporary public key, the fourth hash value, the fifth hash value, a partial private key, the vehicle long-term private key component, and the generator.

[0008] When the new second hash value is equal to the original second hash value and the first element is equal to the second element, the signature is confirmed to be valid, and a set of valid signatures is obtained.

[0009] The temporary public keys in the valid signature set are summed using modulo-based dot addition to obtain an aggregated temporary public key, and the signature components in the valid signature set are summed using modulo-based scalar addition to obtain an aggregated signature component. The aggregated temporary public key and the aggregated signature component together form an aggregated signature.

[0010] The overall validity of the aggregate signature is verified based on the verification equation, the aggregate signature, and the aggregate identifier of the aggregate signature.

[0011] As can be seen, the efficient aggregation anonymous verification method for vehicle ad hoc networks provided in this application first verifies the freshness of the timestamp, ensuring the freshness of the timestamp from the source. Only when the timestamp is confirmed to be valid is the validity of each individual signature further verified. In the validity verification of an individual signature, a new second hash value is calculated based on the temporary public key, the message to be signed, and the roadside unit public key. A first element is calculated based on the signature component and the generator. A second element is calculated based on the temporary public key, the fourth hash value, the fifth hash value, a partial private key, the vehicle long-term private key component, and the generator. The signature is confirmed to be valid only when the new second hash value is equal to the original second hash value and the first element is equal to the second element. This can eliminate invalid signatures received, preparing for the next step of aggregation signature verification. In the aggregation signature verification stage, valid signatures are aggregated and then verified using a verification equation. The overall validity of all signatures can be verified through a single bilinear pairing operation. Compared with the traditional method of verifying each signature individually, which requires multiple bilinear pairing operations, this reduces computational complexity. In high-concurrency scenarios, the processing latency is reduced from seconds to hundreds of milliseconds, which can effectively solve the problem of low efficiency in vehicle-to-everything (V2X) dynamic message authentication and meet real-time requirements.

[0012] Optionally, each signature also includes a globally unique incrementing sequence number. Before calculating the new second hash value based on the temporary public key, the message to be signed, and the roadside unit public key, the method further includes:

[0013] The latest received incrementing sequence number is determined based on the pseudoname corresponding to the currently received incrementing sequence number.

[0014] If the currently received incrementing sequence number is less than or equal to the latest received incrementing sequence number, the signature is determined to be a replay attack, the signature is rejected, and a warning is sent to the vehicle node corresponding to the signature.

[0015] If the currently received incrementing sequence number is greater than the latest received incrementing sequence number, then the currently received incrementing sequence number is updated to the latest received incrementing sequence number, and the step of calculating a new second hash value based on the temporary public key, the message to be signed, and the roadside unit public key is executed.

[0016] As can be seen from the embodiments of this application, before validating each signature, a uniqueness check is first performed based on the sequence number corresponding to each signature to prevent replay attacks. Simultaneously, filtering is performed before aggregated signature verification, which helps reduce computational complexity and thus improves verification efficiency. Furthermore, this avoids chain reactions caused by forged braking, steering, and other critical messages, significantly improving the security of vehicle-to-everything (V2X) communication.

[0017] Optionally, the method further includes:

[0018] If the overall validity of the aggregated signature is invalid, then extract the temporary public key and signature component of each signature in the aggregated signature;

[0019] The temporary public key and signature components of each signature in the aggregated signature are locally aggregated to locate abnormal signatures;

[0020] If the number of abnormal signatures is less than or equal to a preset threshold, then the vehicle node corresponding to the abnormal signature is requested to regenerate and send a new signature.

[0021] If the number of abnormal signatures exceeds a preset threshold, all signatures in the aggregated signatures will be marked as abnormal aggregate groups and stored in the local cache. At the same time, the hash value, failure timestamp, and associated pseudonym set of the abnormal aggregate groups will be recorded on the blockchain through the smart contract interface of the blockchain node, and the quartile positioning attack detection will be triggered.

[0022] As can be seen in this embodiment, if the overall validity of the aggregated signature is invalid, the temporary public key and signature component of each signature in the aggregated signature are extracted and locally aggregated to locate the abnormal signature. Then, the abnormal signatures are classified and processed according to their number. If the number is less than a threshold, the vehicle node corresponding to the abnormal signature is requested to regenerate and send a new signature, which can eliminate the false judgment of aggregated signature failure caused by network latency or temporary calculation errors. If the number is greater than the threshold, all signatures in the aggregated signature are marked as abnormal aggregate groups and stored in the local cache. At the same time, the hash value, failure timestamp, and associated pseudonym set of the abnormal aggregate group are put on the blockchain for evidence through the smart contract interface of the blockchain node, and the quartile positioning attack detection is triggered. This classification and processing mechanism can optimize the signature verification process, thereby improving the verification efficiency.

[0023] Optionally, the triggering of the quartile localization attack detection includes:

[0024] Obtain at least one normal historical aggregate signature from the blockchain node;

[0025] Calculate the temporary public key difference and signature component difference between the abnormal aggregate group and at least one normal historical aggregate signature;

[0026] If the difference between the temporary public key and the difference between the signature components do not satisfy the linear relationship of the elliptic curve, then it is determined that there is an abnormal temporary public key and / or an abnormal signature component in the abnormal aggregation group.

[0027] The abnormal temporary public key and / or the abnormal signature corresponding to the abnormal signature component are determined based on the binary search method.

[0028] The malicious vehicle node is located based on the abnormal signature, and the pseudonym and abnormal signature characteristics of the malicious vehicle node are recorded.

[0029] As can be seen, the embodiments of this application provide a method for detecting quartile positioning attacks. By judging whether the difference between the temporary public key and the difference between the signature component of the abnormal aggregation group and the normal historical aggregation signature satisfies the linear relationship of the elliptic curve, it is determined whether there is an abnormal temporary public key and / or abnormal signature component. Then, the malicious vehicle node is located layer by layer by the quartile method. This helps to solve the problem that traditional solutions cannot locate the specific attack source or mistakenly reject normal nodes, and improves the accuracy of malicious node handling.

[0030] Optionally, the method further includes:

[0031] The registration information of the malicious vehicle node is queried based on the notarization of the blockchain node and the pseudonym of the malicious vehicle node.

[0032] Verify, based on the registration information, whether the binding relationship between the pseudonym of the malicious vehicle node and the identity information of the vehicle terminal hardware of the malicious vehicle node has been tampered with.

[0033] If the binding relationship is tampered with, the abnormal signature is determined to be a pseudonym forgery attack;

[0034] If the binding relationship has not been tampered with, then the malicious vehicle node is determined to be a real malicious node.

[0035] As can be seen in this embodiment, the pseudonym is used as an index to query the registration information of malicious vehicle nodes in the blockchain node's storage, and then it is further determined whether the binding relationship between the pseudonym and the identity information of the vehicle terminal hardware has been tampered with in order to locate the specific cause of failure.

[0036] Optionally, the method further includes:

[0037] The identity revocation operation of the blockchain node is triggered through the smart contract interface, so that the pseudonym of the malicious vehicle node is written into the immutable log of the blockchain node.

[0038] A revocation notification message is broadcast to all vehicle nodes within the area. The revocation notification message carries the pseudonym and revocation timestamp of the malicious vehicle node, so that after receiving the revocation notification message, all vehicle nodes within the area update their local trusted vehicle node list according to the pseudonym and revocation timestamp of the malicious vehicle node and refuse to communicate with the malicious vehicle node.

[0039] As can be seen in this embodiment, if a malicious vehicle node is a real malicious node, it is not only written into the blockchain node to prevent tampering, but also broadcast to other vehicle nodes, so that other vehicle nodes update their local trusted vehicle node list, thereby forming a global blacklist. This enables cross-regional identity tracing and immediate revocation of malicious nodes, thereby preventing malicious nodes from masquerading as normal nodes and committing evil for a long time. It makes up for the defects of the traditional solution's failure of regional isolation and enhances the reliability of vehicle network identity management.

[0040] Optionally, the second hash value is calculated based on a second hash function, which is used to bind the message to be signed, the roadside unit public key, and the temporary public key.

[0041] The fourth hash value is calculated based on the fourth hash function, which is used to bind the system master public key, the temporary public key, and the second hash value. The system master public key is generated based on the master key fragment of the key generation center and the generator.

[0042] The fifth hash value is calculated based on the fifth hash function, which is used to bind the temporary private key corresponding to the temporary public key, the certificate parameters issued by the key generation center, the message to be signed, the first hash value, and the second hash value.

[0043] The first hash value is calculated based on a first hash function, which is used to generate the dynamic pseudo-name;

[0044] The private key is generated based on the vehicle random number, the master key fragment of the key generation center, and the first hash value. The vehicle random number is generated by the vehicle node using a random number generator.

[0045] A second aspect of this application provides a high-efficiency aggregation anonymity verification device for vehicle ad hoc networks, applied to a roadside unit, the device comprising:

[0046] The communication unit is used to receive a signature tuple, pseudonym and timestamp broadcast by the vehicle node. The signature tuple includes multiple signatures, and each signature includes a pair of temporary public keys and a signature component.

[0047] The processing unit is configured to, upon confirming the validity of the timestamp, calculate a new second hash value for each signature based on the temporary public key, the message to be signed, and the roadside unit public key; calculate a first element based on the signature component and the generator; and calculate a second element based on the temporary public key, the fourth hash value, the fifth hash value, a partial private key, the vehicle long-term private key component, and the generator.

[0048] The processing unit is further configured to confirm the validity of the signature and obtain a set of valid signatures when the new second hash value is equal to the original second hash value and the first element is equal to the second element;

[0049] The processing unit is further configured to accumulate the temporary public keys in the valid signature set according to the modulo-based dot addition to obtain the aggregated temporary public key, and to sum the signature components in the valid signature set according to the modulo-based scalar addition to obtain the aggregated signature component, wherein the aggregated temporary public key and the aggregated signature component constitute the aggregated signature.

[0050] The processing unit is also configured to verify the overall validity of the aggregate signature based on the verification equation, the aggregate signature, and the aggregate identifier of the aggregate signature.

[0051] A third aspect of this application provides an electronic device, including: a processor and a memory;

[0052] The processor is connected to a memory, wherein the memory is used to store computer programs and the processor is used to invoke the computer programs to execute the methods as described in the first aspect of the embodiments of this application.

[0053] A fourth aspect of this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, perform the method as described in the first aspect of this application.

[0054] Based on the same inventive concept, the embodiments of this application provide a vehicle ad hoc network high-efficiency aggregation anonymous verification device, electronic device and computer-readable storage medium. The beneficial effects are the same as those in the above method embodiments, and will not be repeated here. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 This application shows a system block diagram of a vehicle networking system according to an embodiment of the present application;

[0057] Figure 2 A flowchart illustrating an efficient aggregation anonymity verification method for vehicle ad hoc networks provided in one embodiment of this application is shown.

[0058] Figure 3 This paper shows a schematic diagram of the structure of a high-efficiency aggregated anonymity verification device for vehicle ad hoc networks provided in one embodiment of this application;

[0059] Figure 4 A schematic diagram of the structure of a computer device provided in one embodiment of this application is shown. Detailed Implementation

[0060] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0061] Please refer to Figure 1 This diagram illustrates a system block diagram of a vehicle-to-everything (V2X) system according to an embodiment of this application. The system may include: a vehicle node group 10, a roadside unit (RSU) group 20, a blockchain node group 30, and a key generation center (KGC) 40, with each node group or unit group including at least one node. Wherein:

[0062] Vehicle node group 10, as the main body for generating and transmitting dynamic messages, generates corresponding parameters through the vehicle-mounted safety chip and broadcasts them to the neighboring RSU through the V2X communication module; at the same time, it maintains an incrementing sequence number locally and synchronizes the time base of the network between blockchain nodes to ensure that the timestamp error does not exceed ±100ms, thus ensuring the freshness and uniqueness of the signature.

[0063] RSU group 20, as the core node for aggregation verification, is responsible for collecting the signature tuples of vehicle node group 10 within a preset time window, verifying the uniqueness of message content through hash table caching, eliminating duplicate signatures, and verifying timestamps. Whether it is within the current time window, signatures that time out will be discarded.

[0064] Blockchain node group 30 serves as a trusted evidence storage and identity management hub, storing the binding hash value of vehicle pseudonyms and vehicle terminal MAC addresses, the hash value of abnormal aggregation groups, and malicious node revocation logs. When an RSU confirms a malicious node ID, it triggers an "identity revocation" operation through a smart contract, marking the ID as "malicious" and writing it into an immutable blockchain log. At the same time, the blockchain nodes synchronize the revocation logs of each RSU to form a global blacklist of malicious nodes, ensuring consistency of node information across regions.

[0065] KGC40 is responsible for generating the parameters of the vehicle-to-everything (V2X) system. First, safety parameters are selected. Used to define the security strength of the system, in this application as For example, see other values. The specific cases are not listed here; subsequently, an elliptic curve group G is defined, and an elliptic curve conforming to international standards is selected. The order of the elliptic curve is a prime number q, and the generator P is a base point in group G, satisfying that the order of P is q; at the same time, a family of hash functions { },in, : Used for dynamic pseudonym generation, the input is four elliptic curve group elements, and the output is a 128-bit hash value; : These are used for binding messages, public keys, and temporary keys; binding identities, public keys, and temporary keys; and binding signature components. The input is a variable-length message and two group elements, and the output is an integer modulo q. This is a multi-parameter composite hash used for signature binding. : The input contains two group elements, a modulo q integer, and two group elements, which are used for on-chain verification of the aggregate signature; : The input consists of group elements, and the output is a 256-bit hash value. All hash functions satisfy collision resistance and anti-image attack properties, consistent with the assumptions of the random oracle model.

[0066] KGC40 generates master key And calculate the system public key. Where · represents elliptic curve dot product; to avoid the risk of single-point leakage of the master key, the Shamir threshold secret sharing scheme is adopted (the threshold is set to ). (where n is the total number of blockchain nodes), the master key s is decomposed into n secret fragments s'_1, s'_2, ..., s'_n. s can be recovered only when at least t fragments are aggregated. The fragments are distributed to the n nodes of the blockchain for storage through a secure channel.

[0067] KGC40 will set system parameters The data is packaged into structured data and written into the genesis block of the blockchain node. The blockchain network adopts the Byzantine Fault Tolerance (BFT) consensus mechanism, which requires at least 2 / 3 of the nodes to pass the signature verification of the new block before the parameter block can be confirmed as a valid block. This ensures that the system parameters stored by all nodes are completely consistent and avoids subsequent signature verification failures due to parameter discrepancies.

[0068] The deployment of blockchain node group 30 includes an Identity Authentication Contract (IAC) and an Aggregate Signature Verification Contract (ASVC). The IAC is used to define pseudonym update rules, malicious node judgment criteria, and punishment measures. The ASVC is used to implement efficient verification logic for multi-signature aggregation, supporting RSU to aggregate the signatures of multiple vehicles into a single signature and quickly verify its validity.

[0069] KGC40 generates the initial encryption factor seed. A 256-bit random number is generated and passed through the blockchain node's oracle. Injected into the local storage of vehicle node group 10; encryption factor periodically. Dynamically updated, the update formula is: ,in This is the current timestamp. The output of the 128-bit hash function defined above is truncated to 256 bits as a new encryption factor, resulting in the updated hash function. Transmitted to vehicle node group 10 via a secure channel and overwrites the old value; for example, The time is kept to ensure it is less than half the safety parameter value to defend against replay attacks.

[0070] When vehicle node group 10 starts, it obtains system parameter pp through the blockchain application programming interface (API) and calculates... Perform on the base point P of the elliptic curve Hash operation; the parameter verification value pre-stored locally on the node is ,like If the parameters are inconsistent, a local alarm will be triggered and access to the vehicle network communication network will be refused. At the same time, the abnormal information will be reported to the regulatory node through blockchain transactions.

[0071] The registration process for new vehicle nodes is as follows:

[0072] Newly registered vehicle nodes submit registration requests to KGC40, including their real identities. Hardware identifier (VIN) and device public key The KGC40 first verifies the validity of the VIN code, and then verifies the device's public key. The signature validity. Newly registered vehicle nodes need to verify the signature validity. The KGC40 uses a pre-allocated device private key to verify the signature, and after successful verification, it generates an initial private key component for the vehicle. The hash value of the KGC40 master key and the vehicle VIN code is used. XOR generation, i.e. This ensures that the private key is bound to the vehicle's identity and calculates the corresponding public key. .

[0073] Newly registered vehicle nodes will use pseudonyms. Public key Registration timestamp The VIN code is packaged into a registration transaction, and the transaction signature field contains the vehicle's device private key pair. and signature The transaction is broadcast to blockchain node 30 via the P2P network. At least two-thirds of the blockchain nodes verify the signature validity using the device's public key. verify After ensuring parameter consistency, the transaction is packaged into a new block and added to the blockchain; the blockchain then returns the hash value of the transaction. As the unique identity credential of a vehicle node on the blockchain, it must be referenced for subsequent signature generation and verification. Based on associated identity.

[0074] Please refer to Figure 2 This document illustrates a flowchart of an efficient aggregation anonymity verification method for vehicle ad hoc networks provided in one embodiment of this application. This method can be applied to... Figure 1 The roadside unit 10 is shown. The method may include the following steps:

[0075] Step 201: Receive the signature tuple, pseudonym and timestamp broadcast by the vehicle node. The signature tuple includes multiple signatures, and each signature includes a pair of temporary public keys and a signature component.

[0076] Among them, temporary public keys It is the generator P of the vehicle node based on the elliptic curve group G and the temporary private key. The calculation is obtained through the dot product of elliptic curves, and the formula is as follows: Temporary private key The vehicle node is selected from the modulo q residual group by a random number generator. The random number generator selected can be either a true random number generator or a pseudo random number generator; no limitation is made here. For example, it could be a true random number generator conforming to the NIST SP 800-90A standard. This random number generator must be FIPS 140-2 security certified to ensure the output... The elements are uniformly distributed within the group, meaning the probability error of each element does not exceed 2−128, thus avoiding the possibility that the signature could be predictable or cracked by quantum computing attacks due to random number bias.

[0077] Temporary public key The specific generation operation is as follows: Convert to binary, perform scalar multiplication with modulo addition and doubling operations on the x-coordinate of P, and finally obtain... The coordinates (x, y) satisfy the equation of the elliptic curve. (Where a and b are elliptic curve parameters). It should be noted that this temporary public key... Valid only in this round of signing, its randomness is determined by... The uniform distribution ensures the timeliness and resistance to replay attacks of the current signature.

[0078] Furthermore, the method also includes ensuring the legitimacy of the temporary key pair through dual authentication. Specifically: first, check... ,Right now and If true, then verify. To determine if a point is a valid point of group G, substitute (x, y) into the elliptic curve equation. If the equation holds, then the point is considered valid. Valid; if verification fails (e.g., x or y exceeds the modulus q, or the equation is not satisfied), then regenerate. The calculation is repeated until a valid temporary key pair is obtained. .

[0079] Among them, the signature component The vehicle node uses a temporary private key Fifth hash value Partial private key Fourth hash value and vehicle long-term private key component The generated, specific calculation formula is as follows:

[0080]

[0081] in, ,and , s′ represents the true identity of the vehicle node, and s′ represents the key fragment pre-allocated by KGC. for Multiplicative inverse modulo q.

[0082] Wherein, the fourth hash value It is based on the fourth hash function The calculated fourth hash function Used to bind the system's public key. The temporary public key Second hash value The specific calculation formula is as follows: , This refers to the public key of the roadside unit; "||" indicates string concatenation. The system's master public key... It is generated based on the master key fragment s from the key generation center and the generator P, and the specific calculation formula is as follows: .

[0083] Wherein, the second hash value It is based on the second hash function The calculated second hash function Used to bind the message to be signed. The public key of the roadside unit and the temporary public key The specific calculation formula is as follows: .

[0084] Among them, the fifth hash value It is based on the fifth hash function The calculated fifth hash function Used to bind the temporary public key The corresponding temporary private key Certificate parameters issued by the key generation center The message to be signed First hash value and the second hash value The specific calculation formula is as follows: .

[0085] Wherein, the first hash value It is based on the first hash function The calculated first hash function Used to generate the dynamic pseudo-name .

[0086] Among them, the private key It is based on vehicle random numbers The master key fragment s of the key generation center and the first hash value The generated vehicle random number The number is generated by the vehicle node using a random number generator.

[0087] Among them, timestamp It is the vehicle node that is signing. Generated later using the local clock of the vehicle node; pseudonym It is based on the latest encryption factor Random numbers for vehicles timestamp Vehicle long-term private key component Corresponding public key The true identity of the vehicle node and the first hash function The generated, specific calculation formula is as follows: ,in Indicates the hash output (128 bits) and The bitwise XOR operation of the x-coordinate (256 bits) (truncating the hash value to 256 bits and taking the first 128 bits), public key Based on the vehicle's long-term private key components Generates with generator P, and the specific calculation formula is as follows: .

[0088] At the same time, encryption factor The update cycle is Based on the previous round of encryption factors and current timestamp The first hash function is then used for updating, and the specific calculation formula is as follows: Furthermore, if abnormal communication is detected within the period, it will be triggered in advance. The recalculation reduces the security risks caused by long-term use of the same factor.

[0089] It can be seen that, in the embodiments of this application, because and The dynamism of each round of pseudonyms Its uniqueness probability is as high as 1 / 2128, which can effectively resist identity tracking attacks.

[0090] Step 202: Upon confirming the validity of the timestamp, for each signature, calculate a new second hash value based on the temporary public key, the message to be signed, and the roadside unit public key; calculate a first element based on the signature component and the generator; and calculate a second element based on the temporary public key, the fourth hash value, the fifth hash value, the partial private key, the vehicle long-term private key component, and the generator.

[0091] Specifically, confirming the validity of the timestamp may include: the roadside unit obtaining its own local time. Then and Compare the values ​​and determine whether the difference is less than or equal to the preset time difference. ,Right now If so, then confirm the timestamp. Valid. For example, The default settings are 5 seconds, 10 seconds, 20 seconds, 30 seconds, etc. If not, please confirm the timestamp. Invalid. The corresponding message to be signed is determined to be a replay of a historical message. Verification is rejected and a warning is triggered.

[0092] Simultaneously, the roadside unit can also maintain a timestamp cache based on a hash table. The key is the hash value of the message content, and the value is the timestamp of the most recently received message. If the timestamp of the same message is found to be duplicated (i.e., the same timestamp exists in the cache), the cache will be updated accordingly. And the timestamp difference is less than or equal to If the condition is not met, it is considered a replay attack and the attack is rejected.

[0093] Step 203: When the new second hash value is equal to the original second hash value and the first element is equal to the second element, confirm that the signature is valid and obtain a set of valid signatures.

[0094] For example, the formula for calculating the second hash value is: The new second hash value is calculated by the roadside unit based on the received signature. The original second hash value is calculated by the roadside unit using parameters obtained from the blockchain node. By comparing whether the two are equal, it can be determined whether the relevant parameters have changed, thereby determining the validity of the signature.

[0095] For example, according to the signature component The first element is calculated using the generator P, and the formula is as follows: According to the temporary public key Fourth hash value Fifth hash value Partial private key Vehicle long-term private key component The second element is calculated using the generator P, and the calculation formula is as follows: The validity of a signature is determined by comparing whether the first and second elements are equal to determine whether it satisfies the equation of an elliptic curve.

[0096] In this embodiment of the application, by verifying each signature individually, all valid signatures are determined, thereby obtaining a set of valid signatures. .

[0097] Step 204: Accumulate the temporary public keys in the valid signature set according to the modulo-based dot addition method to obtain the aggregated temporary public key, and sum the signature components in the valid signature set according to the modulo-based scalar addition method to obtain the aggregated signature component. The aggregated temporary public key and the aggregated signature component constitute the aggregated signature.

[0098] For example, aggregate temporary public keys Aggregate signature components The complete aggregate signature is .

[0099] Furthermore, a unique aggregate identifier can be generated by hashing the aggregate signature using a sixth hash function. It is used for the unique identification and rapid verification of aggregate signatures in the subsequent verification stage.

[0100] Step 205: Verify the overall validity of the aggregate signature based on the verification equation, the aggregate signature, and the aggregate identifier of the aggregate signature.

[0101] For example, the verification equation is:

[0102]

[0103] Furthermore, it is also possible to target multiple hash values ​​involved in the aggregation process (such as...) , , RSU uses a Merkle tree structure for compression. Each signature... As leaf nodes, construct a Merkle tree and compute the root hash. , only With aggregate signature Synchronous storage. Only verification is required during verification. The association with aggregated signatures significantly reduces storage and transmission overhead.

[0104] As can be seen, the efficient aggregation anonymous verification method for vehicle ad hoc networks provided in this application first verifies the freshness of the timestamp, ensuring the freshness of the timestamp from the source. Only when the timestamp is confirmed to be valid is the validity of each individual signature further verified. In the validity verification of an individual signature, a new second hash value is calculated based on the temporary public key, the message to be signed, and the roadside unit public key. A first element is calculated based on the signature component and the generator. A second element is calculated based on the temporary public key, the fourth hash value, the fifth hash value, a partial private key, the vehicle long-term private key component, and the generator. The signature is confirmed to be valid only when the new second hash value is equal to the original second hash value and the first element is equal to the second element. This can eliminate invalid signatures received, preparing for the next step of aggregation signature verification. In the aggregation signature verification stage, valid signatures are aggregated and then verified using a verification equation. The overall validity of all signatures can be verified through a single bilinear pairing operation. Compared with the traditional method of verifying each signature individually, which requires multiple bilinear pairing operations, this reduces computational complexity. In high-concurrency scenarios, the processing latency is reduced from seconds to hundreds of milliseconds, which can effectively solve the problem of low efficiency in vehicle-to-everything (V2X) dynamic message authentication and meet real-time requirements.

[0105] In one embodiment provided in this application, each signature also includes a globally unique incrementing sequence number. Before calculating the new second hash value based on the temporary public key, the message to be signed, and the roadside unit public key, the method further includes:

[0106] Based on the currently received incrementing sequence number Corresponding pseudo-name Determine the currently received incrementing sequence number The corresponding latest received incrementing sequence number ;

[0107] If the currently received incrementing sequence number Less than or equal to the latest received incrementing sequence number (Right now If the signature is identified as a replay attack, the signature is rejected and a warning is sent to the vehicle node corresponding to the signature.

[0108] If the currently received incrementing sequence number Greater than the latest received incrementing sequence number (Right now Then the currently received incrementing sequence number will be... Updated to the latest received incrementing sequence number The process then proceeds to calculate a new second hash value based on the temporary public key, the message to be signed, and the roadside unit public key.

[0109] As can be seen from the embodiments of this application, before validating each signature, a uniqueness check is first performed based on the sequence number corresponding to each signature to prevent replay attacks. Simultaneously, filtering is performed before aggregated signature verification, which helps reduce computational complexity and thus improves verification efficiency. Furthermore, this avoids chain reactions caused by forged braking, steering, and other critical messages, significantly improving the security of vehicle-to-everything (V2X) communication.

[0110] In one embodiment provided in this application, the method further includes:

[0111] If the overall validity of the aggregated signature is invalid, then extract the temporary public key and signature component of each signature in the aggregated signature;

[0112] The temporary public key and signature components of each signature in the aggregated signature are locally aggregated to locate abnormal signatures;

[0113] If the number of abnormal signatures is less than or equal to a preset threshold, then the vehicle node corresponding to the abnormal signature is requested to regenerate and send a new signature.

[0114] If the number of abnormal signatures exceeds a preset threshold, all signatures in the aggregated signatures will be marked as abnormal aggregate groups and stored in the local cache. At the same time, the hash value, failure timestamp, and associated pseudonym set of the abnormal aggregate groups will be recorded on the blockchain through the smart contract interface of the blockchain node, and the quartile positioning attack detection will be triggered.

[0115] The preset threshold can be, for example, 5%, 10%, 15%, 20% of the valid signatures, etc. The cache time can be set to 1 time window, 2 time windows, or 3 time windows, and each time window can be 10 seconds, 20 seconds, 30 seconds, etc., without any limitation.

[0116] As can be seen in this embodiment, if the overall validity of the aggregated signature is invalid, the temporary public key and signature component of each signature in the aggregated signature are extracted and locally aggregated to locate the abnormal signature. Then, the abnormal signatures are classified and processed according to their number. If the number is less than a threshold, the vehicle node corresponding to the abnormal signature is requested to regenerate and send a new signature, which can eliminate the false judgment of aggregated signature failure caused by network latency or temporary calculation errors. If the number is greater than the threshold, all signatures in the aggregated signature are marked as abnormal aggregate groups and stored in the local cache. At the same time, the hash value, failure timestamp, and associated pseudonym set of the abnormal aggregate group are put on the blockchain for evidence through the smart contract interface of the blockchain node, and the quartile positioning attack detection is triggered. This classification and processing mechanism can optimize the signature verification process, thereby improving the verification efficiency.

[0117] In one embodiment provided in this application, the triggering of the quartile localization attack detection includes:

[0118] Obtain at least one normal historical aggregate signature from the blockchain node;

[0119] Calculate the temporary public key difference and signature component difference between the abnormal aggregate group and at least one normal historical aggregate signature;

[0120] If the difference between the temporary public key and the difference between the signature components do not satisfy the linear relationship of the elliptic curve, then it is determined that there is an abnormal temporary public key and / or an abnormal signature component in the abnormal aggregation group.

[0121] The abnormal temporary public key and / or the abnormal signature corresponding to the abnormal signature component are determined based on the binary search method.

[0122] The malicious vehicle node is located based on the abnormal signature, and the pseudonym and abnormal signature characteristics of the malicious vehicle node are recorded.

[0123] For example, a majority vote could be used to obtain the normal historical aggregate signature. The number of k can be odd (i.e., k is odd), to calculate the abnormal aggregation group. With each normal historical aggregate signature Temporary public key differences Differences between signature components If more than half of the differences do not satisfy the linear relationship of the elliptic curve, it is determined that there are anomalous temporary public keys and / or anomalous signature components in the anomalous aggregation group. The linear relationship of the elliptic curve is as follows:

[0124]

[0125] For example, the abnormal temporary public key and / or the abnormal signature corresponding to the abnormal signature component are determined based on the binary search method. That is, based on the difference analysis results, RSU sorts the abnormal aggregation group S (initially all nodes in the current batch) by pseudo-name hash value and then divides it into two parts. and Extract respectively and Recalculate the local aggregate signature of the signature components and .like Verification failed If successful, the malicious node will be in In the middle; conversely, in the middle. In the middle. Repeat this binary search process (at most). (where n is the number of suspicious nodes), eventually locating the specific malicious node i and recording its pseudonym. With abnormal signature features (such as abnormal) hash value ).

[0126] As can be seen, the embodiments of this application provide a method for detecting quartile positioning attacks. By judging whether the difference between the temporary public key and the difference between the signature component of the abnormal aggregation group and the normal historical aggregation signature satisfies the linear relationship of the elliptic curve, it is determined whether there is an abnormal temporary public key and / or abnormal signature component. Then, the malicious vehicle node is located layer by layer by the quartile method. This helps to solve the problem that traditional solutions cannot locate the specific attack source or mistakenly reject normal nodes, and improves the accuracy of malicious node handling.

[0127] In one embodiment provided in this application, the method further includes:

[0128] The registration information of the malicious vehicle node is queried based on the notarization of the blockchain node and the pseudonym of the malicious vehicle node.

[0129] Verify, based on the registration information, whether the binding relationship between the pseudonym of the malicious vehicle node and the identity information of the vehicle terminal hardware of the malicious vehicle node has been tampered with.

[0130] If the binding relationship is tampered with, the abnormal signature is determined to be a pseudonym forgery attack;

[0131] If the binding relationship has not been tampered with, then the malicious vehicle node is determined to be a real malicious node.

[0132] For example, the binding relationship is as follows: .

[0133] As can be seen in this embodiment, the pseudonym is used as an index to query the registration information of malicious vehicle nodes in the blockchain node's storage, and then it is further determined whether the binding relationship between the pseudonym and the identity information of the vehicle terminal hardware has been tampered with in order to locate the specific cause of failure.

[0134] In one embodiment provided in this application, the method further includes:

[0135] The identity revocation operation of the blockchain node is triggered through the smart contract interface, so that the pseudonym of the malicious vehicle node is written into the immutable log of the blockchain node.

[0136] A revocation notification message is broadcast to all vehicle nodes within the area. The revocation notification message carries the pseudonym and revocation timestamp of the malicious vehicle node, so that after receiving the revocation notification message, all vehicle nodes within the area update their local trusted vehicle node list according to the pseudonym and revocation timestamp of the malicious vehicle node and refuse to communicate with the malicious vehicle node.

[0137] As can be seen in this embodiment, if a malicious vehicle node is a real malicious node, it is not only written into the blockchain node to prevent tampering, but also broadcast to other vehicle nodes, so that other vehicle nodes update their local trusted vehicle node list, thereby forming a global blacklist. This enables cross-regional identity tracing and immediate revocation of malicious nodes, thereby preventing malicious nodes from masquerading as normal nodes and committing evil for a long time. It makes up for the defects of the traditional solution's failure of regional isolation and enhances the reliability of vehicle network identity management.

[0138] Figure 3 A schematic diagram of a high-efficiency aggregation anonymity verification device for vehicle ad hoc networks according to an embodiment of this application is shown. Applied to a roadside unit, the device includes:

[0139] Communication unit 301 is used to receive a signature tuple, pseudonym and timestamp broadcast by vehicle node, wherein the signature tuple includes multiple signatures, and each signature includes a pair of temporary public keys and signature components;

[0140] Processing unit 302 is configured to, upon confirming the validity of the timestamp, calculate a new second hash value for each signature based on the temporary public key, the message to be signed, and the roadside unit public key; calculate a first element based on the signature component and the generator; and calculate a second element based on the temporary public key, the fourth hash value, the fifth hash value, a partial private key, the vehicle long-term private key component, and the generator.

[0141] The processing unit 302 is further configured to confirm the validity of the signature and obtain a set of valid signatures when the new second hash value is equal to the original second hash value and the first element is equal to the second element;

[0142] The processing unit 302 is further configured to accumulate the temporary public keys in the valid signature set according to the modulo-based dot addition to obtain the aggregated temporary public key, and to sum the signature components in the valid signature set according to the modulo-based scalar addition to obtain the aggregated signature component, wherein the aggregated temporary public key and the aggregated signature component constitute the aggregated signature.

[0143] The processing unit 302 is further configured to verify the overall validity of the aggregate signature based on the verification equation, the aggregate signature, and the aggregate identifier of the aggregate signature.

[0144] Figure 4 The diagram illustrates the structure of a computer device according to an embodiment of this application, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the functions of the computer system of the efficient aggregation anonymity verification method for vehicle ad hoc networks in any of the above embodiments.

[0145] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer, causes the computer to perform the functions of the computer system of the efficient aggregation anonymity verification method for vehicle ad hoc networks in any of the above embodiments.

[0146] This application also provides a computer program product containing instructions that, when executed by a computer, cause the computer to perform the functions of the computer system of the efficient aggregation anonymity verification method for vehicle ad hoc networks in any of the above embodiments.

[0147] It is understood that the specific examples in this application are only intended to help those skilled in the art better understand the implementation methods of this application, and are not intended to limit the scope of the invention.

[0148] It is understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not limit the implementation process of the embodiments of this application in any way.

[0149] It is understood that the various implementation methods described in this application can be implemented individually or in combination, and the implementation methods in this application are not limited in this respect.

[0150] Unless otherwise stated, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this application includes any and all combinations of one or more of the associated listed items. The singular forms "a," "the," and "the" as used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0151] It is understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0152] It is understood that the memory in the embodiments of this application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Specifically, non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0153] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0154] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the aforementioned method implementations, and will not be repeated here.

[0155] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0156] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0157] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0158] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0159] The above are merely specific embodiments of this application, but the scope of protection of this invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this invention should be determined by the scope of the claims.

Claims

1. A vehicular ad hoc network efficient aggregation anonymous verification method, characterized in that, The method is applied to a road side unit, and comprises the following steps: receiving a signature tuple, a pseudonym and a timestamp broadcast by a vehicle node, the signature tuple comprising a plurality of signatures, each signature comprising a pair of a temporary public key and a signature component; when confirming that the timestamp is valid, for each signature, calculating a new second hash value according to the temporary public key, a message to be signed and a road side unit public key, a first element according to the signature component and a generator, and a second element according to the temporary public key, a fourth hash value, a fifth hash value, a partial private key, a vehicle long-term private key component and the generator; when the new second hash value is equal to an original second hash value and the first element is equal to the second element, confirming that the signature is valid, and obtaining a valid signature set; accumulating the temporary public keys in the valid signature set according to point addition under a modulus to obtain an aggregated temporary public key, and summing the signature components in the valid signature set according to scalar addition under a modulus to obtain an aggregated signature component, the aggregated temporary public key and the aggregated signature component forming an aggregated signature; verifying the overall validity of the aggregated signature according to a verification equation and the aggregated signature and an aggregated identifier of the aggregated signature; wherein: the second hash value is calculated according to a second hash function, the second hash function being used to bind the message to be signed, the road side unit public key and the temporary public key; the fourth hash value is calculated according to a fourth hash function, the fourth hash function being used to bind a system master public key, the temporary public key and the second hash value, the system master public key being generated according to a master key fragment of a key generation center and the generator; the fifth hash value is calculated according to a fifth hash function, the fifth hash function being used to bind a temporary private key corresponding to the temporary public key, a certificate parameter issued by the key generation center, the message to be signed, a first hash value and the second hash value; the first hash value is calculated according to a first hash function, the first hash function being used to generate a dynamic pseudonym; the partial private key is generated according to a vehicle random number, the master key fragment of the key generation center and the first hash value, the vehicle random number being generated by the vehicle node according to a random number generator.

2. The method of claim 1, wherein, Each signature further comprises a globally unique increasing serial number, and before the step of calculating a new second hash value according to the temporary public key, a message to be signed and a road side unit public key, the method further comprises the following steps: determining a latest received increasing serial number corresponding to a currently received increasing serial number according to a pseudonym corresponding to the currently received increasing serial number; if the currently received increasing serial number is less than or equal to the latest received increasing serial number, determining that the signature is a replay attack, rejecting the signature and sending a warning to a vehicle node corresponding to the signature. if the current received incremental sequence number is greater than the latest received incremental sequence number, updating the current received incremental sequence number as the latest received incremental sequence number, and performing the step of calculating a new second hash value according to the temporary public key, the message to be signed, and the roadside unit public key.

3. The method of claim 1, wherein, The method further comprises: if the overall validity of the aggregated signature is invalid, extracting the temporary public key and the signature component of each signature in the aggregated signature; locating abnormal signatures by locally aggregating the temporary public key and the signature component of each signature in the aggregated signature; if the number of abnormal signatures is less than or equal to a preset threshold, requesting the vehicle node corresponding to the abnormal signature to regenerate and send a new signature; if the number of abnormal signatures is greater than the preset threshold, marking all signatures in the aggregated signature as an abnormal aggregation group and storing them in a local cache, and uploading the hash value, failure timestamp, and associated pseudonym set of the abnormal aggregation group to the blockchain node through the smart contract interface of the blockchain node for storage and triggering a bisecting location attack detection.

4. The method of claim 3, wherein, The triggering of the bisecting location attack detection comprises: obtaining at least one normal historical aggregated signature from the blockchain node; calculating the temporary public key difference and the signature component difference between the abnormal aggregation group and at least one normal historical aggregated signature; if the temporary public key difference and the signature component difference do not satisfy the linear relationship of the elliptic curve, determining that there is an abnormal temporary public key and / or an abnormal signature component in the abnormal aggregation group; determining the abnormal signature corresponding to the abnormal temporary public key and / or the abnormal signature component based on the bisection method; locating a malicious vehicle node according to the abnormal signature, and recording the pseudonym and abnormal signature characteristics of the malicious vehicle node.

5. The method of claim 4, wherein, The method further comprises: querying the registration information of the malicious vehicle node according to the storage of the blockchain node and the pseudonym of the malicious vehicle node; verifying whether the binding relationship between the pseudonym of the malicious vehicle node and the identity information of the hardware of the on-board terminal of the malicious vehicle node is tampered with according to the registration information; if the binding relationship is tampered with, determining that the abnormal signature is a pseudonym forgery attack; if the binding relationship is not tampered with, determining that the malicious vehicle node is a real malicious node.

6. The method of claim 5, wherein, The method further comprises: triggering the identity revocation operation of the blockchain node through the smart contract interface, so that the pseudonym of the malicious vehicle node is written into the tamper-proof log of the blockchain node; broadcasting a revocation notification message to all vehicle nodes in the region, the revocation notification message carrying the pseudonym and revocation timestamp of the malicious vehicle node, so that all vehicle nodes in the region update the local trusted vehicle node list according to the pseudonym and revocation timestamp of the malicious vehicle node after receiving the revocation notification message, and refuse to communicate with the malicious vehicle node.

7. A vehicular ad hoc network efficient aggregation anonymous verification apparatus characterized by comprising: The device comprises: a communication unit configured to receive a signature tuple, a pseudonym, and a timestamp broadcast by a vehicle node, the signature tuple comprising a plurality of signatures, each signature comprising a pair of a temporary public key and a signature component; a processing unit configured to, upon confirming that the timestamp is valid, for each signature, compute a new second hash value based on the ephemeral public key, the message to be signed, and the roadside unit public key, compute a first element based on the signature component and the generator, and compute a second element based on the ephemeral public key, a fourth hash value, a fifth hash value, a partial private key, a vehicle long-term private key component, and the generator; the processing unit is further configured to, upon the new second hash value being equal to the original second hash value and the first element being equal to the second element, confirm that the signature is valid, and obtain a valid signature set; the processing unit is further configured to accumulate the ephemeral public keys in the valid signature set based on point addition under a modulus to obtain an aggregated ephemeral public key, and sum the signature components in the valid signature set based on scalar addition under a modulus to obtain an aggregated signature component, the aggregated ephemeral public key and the aggregated signature component forming an aggregated signature; the processing unit is further configured to verify the overall validity of the aggregated signature based on a verification equation and the aggregated signature and an aggregated identifier of the aggregated signature; wherein: the second hash value is computed based on a second hash function, the second hash function being configured to bind the message to be signed, the roadside unit public key, and the ephemeral public key; the fourth hash value is computed based on a fourth hash function, the fourth hash function being configured to bind a system master public key, the ephemeral public key, and the second hash value, the system master public key being generated based on a master key fragment of a key generation center and the generator; the fifth hash value is computed based on a fifth hash function, the fifth hash function being configured to bind an ephemeral private key corresponding to the ephemeral public key, a certificate parameter issued by the key generation center, the message to be signed, a first hash value, and the second hash value; the first hash value is computed based on a first hash function, the first hash function being configured to generate the dynamic pseudonym; the partial private key is generated based on a vehicle random number, the master key fragment of the key generation center, and the first hash value, the vehicle random number being generated by the vehicle node based on a random number generator.

8. An electronic device, comprising: comprise: a processor and a memory; the processor and the memory are connected, wherein the memory is configured to store a computer program, and the processor is configured to invoke the computer program to execute the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, the computer program comprising program instructions, the program instructions being executed by a processor to execute the method according to any one of claims 1-6.

Images