A privacy protection security aggregation method for internet of vehicles data sharing based on DMCFE

Abstract

The application belongs to the technical field of Internet of Vehicles data sharing, and discloses a privacy protection security aggregation method for Internet of Vehicles data sharing based on DMCFE. A data producer generates a long-term key to a block chain, publishes a task to an aggregator, constructs the task to a collector, acquires the task, generates an anonymous key and a Sok knowledge signature; the collector performs identity legality verification, and feeds back the verification result to the data producer; the data producer generates an encryption key and encrypted data, and uploads the commitment, range proof and encrypted data to the collector; after the collector performs evidence aggregation and aggregation robustness verification, the collector uploads a vehicle anonymous public key to the block chain; the collector generates a participation credential to the data producer; the data producer calculates a mask by aggregating polynomial results, uploads part of the decryption key to the collector, and the collector uploads an encrypted data set and part of the decryption key set to the aggregator; and the aggregator aggregates decryption to a data requester.

Description

Technical Field

[0001] This invention relates to the field of vehicle network data sharing technology, and in particular to a privacy-preserving and secure aggregation method for vehicle network data sharing based on DMCFE. Background Technology

[0002] With the development of vehicle-to-everything (V2X) technology, large-scale vehicles can generate rich numerical perception data in real time, such as speed, location, road travel time, and ambient temperature. Simultaneously, improvements in onboard hardware capabilities have enabled vehicles to gradually acquire local storage and processing capabilities, allowing for temporary storage and selective sharing of perception data. Besides traffic management centers, navigation service providers, urban traffic regulatory agencies, and intelligent mobility platforms also need to access traffic statistics for different road segments and time periods, such as average road speed, vehicle density, total vehicle travel time, and regional congestion status, to provide efficient services in real-time traffic management, route planning, congestion prediction, and signal control scenarios. Therefore, building a safe data sharing platform for large-scale vehicles is of great significance. With the development of edge computing, Roadside Units (RSUs) can perform preliminary processing of vehicle perception data, thereby reducing the computational and communication load on the central platform. Utilizing Vehicle-to-Infrastructure (V2I) communication, the data sharing platform can collect perception data within the current time period and target area as needed, generate statistical results through aggregation operations such as inner product calculation or weighted summation, and ultimately provide real-time results to data requesters. Existing research has proposed a dynamic traffic signal control method based on vehicle swarm intelligence perception data. By aggregating information such as vehicle speed at intersections, waiting queue length, and vehicle travel time, the method dynamically adjusts traffic light switching strategies to shorten congestion duration and alleviate urban road congestion.

[0003] However, vehicle perception data often contains highly sensitive information. Once this data is leaked, attackers could further infer the vehicle's driving trajectory, behavior patterns, travel habits, and even its true identity. Therefore, how to ensure data availability while protecting data privacy has become a crucial issue that cannot be ignored in vehicle-to-everything (V2X) data sharing. The EU's General Data Protection Regulation (GDPR) emphasizes personal data protection and outlines several important principles: First, the minimization of data collection and processing, meaning that data consumers can only collect and process the minimum amount of data strictly required for a specific purpose; second, the right to access, meaning that data providers have the right to know how and for what purpose the recipient uses the data, and that data use must be consistent with its intended use; and third, the right to be forgotten, meaning that when data services are terminated, the system should establish a revocation mechanism to ensure that the data purchaser cannot continue to access or reuse the data. These principles require data sharing systems to achieve "data available but not visible," meaning that data recipients can only obtain the authorized processing results and cannot directly obtain or permanently retain the original data.

[0004] Based on the above concepts, such as Figure 1As shown, the vehicle-to-everything (V2X) data sharing model considered in this invention is as follows: a data requester initiates a statistical computation task, registers a vehicle to respond to the task and uploads encrypted sensing data, and the data sharing platform completes the aggregation computation and returns the results to the data requester. Existing privacy protection technologies still have significant limitations in V2X data sharing scenarios. Multi-Party Computation (MPC) typically relies on multiple rounds of interaction and assumes that some participants are honest, resulting in high computational and communication overhead, making it difficult to meet the needs of large-scale real-time data processing. Homomorphic Encryption (HE) allows computation to be performed on ciphertext, but single-key homomorphic encryption can easily lead to systemic privacy leaks if key management is inadequate; once the decryption private key or public key management mechanism is compromised, attackers may be able to analyze or crack large amounts of encrypted data. While multi-key homomorphic encryption can alleviate the trust concentration problem caused by single-key encryption, the ciphertext size is large, and the computational complexity is high, making it difficult to adapt to high-concurrency V2X tasks. Trusted Execution Environments (TEEs) construct secure execution domains through hardware isolation mechanisms, ensuring data processing within a trusted environment. However, they are highly dependent on specific hardware, have high deployment barriers and maintenance costs, and most solutions assume the TEE is completely trusted. While Federated Learning (FL) enables collaborative model training across distributed nodes, multiple iterations incur high computational overhead, and intermediate models may be at risk of information leakage, making it difficult to fully guarantee data security in the not-fully-trusted environment of connected vehicles. Against this backdrop, Decentralized Multi-Client Functional Encryption (DMCFE) provides a new technological paradigm for connected vehicle data sharing. DMCFE allows multiple clients to independently generate encryption keys and upload ciphertext. The aggregator can only obtain the computation result of a specified function and cannot recover the original input of a single client. Because each client independently generates a unique encryption key, even if multiple clients or cloud servers are attacked, the decryption key is difficult to recover, thus resisting collusion attacks between clients and servers. Meanwhile, DMCFE does not rely on trusted third parties, effectively avoiding single points of failure and potential attack risks, and enhancing the overall security of the aggregation process.

[0005] The DMCFE-based vehicle-to-everything (V2X) data sharing process involves the following steps: First, each vehicle generates a unique key and combines it with a task tag to encrypt its private data. Then, users generate a partial decryption key using their unique key, user set, and weight vector. The collector sends the collected encrypted dataset and partial decryption key set to the aggregator. The aggregator first aggregates the partial decryption key set into a decryption key. Finally, the aggregator uses the decryption key to aggregate the encrypted dataset into a function output. The key to this inner product function lies in the weighted sum of multi-user data. However, in V2X data sharing, focusing solely on data privacy protection is insufficient. Vehicle data typically possesses strong temporal and spatial attributes; a vehicle's participation in a perception task may reveal its current location, driving trajectory, and travel patterns. When the same vehicle participates in tasks in adjacent areas or within similar time periods for an extended period, attackers may infer individual vehicle contributions through changes in the participation set and differences in the aggregation results. Simultaneously, vehicle-uploaded data typically originates from actual perception devices such as GPS, speedometers, and environmental sensors, making it susceptible to GPS drift, signal obstruction, multipath effects, and complex road environments, resulting in outliers or data exceeding reasonable physical limits. Without an effective data filtering mechanism, abnormal data, once included in aggregation, can significantly impact the aggregation results, potentially misleading applications such as traffic scheduling and safety decision-making. Therefore, while existing DMCFE solutions can protect the plaintext content of vehicle-uploaded data, they primarily address the problem of "how to calculate aggregation results in encrypted form," and cannot directly meet the requirements of vehicle anonymity, cross-wheel non-association, and verification of perception data validity in vehicle-to-everything (V2X) data sharing. In summary, when existing DMCFE solutions are directly applied to V2X data sharing scenarios, they still face the following two challenges: Challenge 1: Strong Identity Privacy Protection. Existing DMCFE schemes typically assign a fixed number to each member in the system during the initialization phase. During each round of aggregation, participants and the aggregator need to know the specific participant's identity or number to ensure the correctness of mask cancellation and secure aggregation. However, this mechanism allows vehicle participation behavior to be continuously correlated across multiple rounds, increasing the risk of identity privacy leakage. While some schemes can mitigate cross-round differential leakage, they usually only hide the identity from the aggregator, failing to hide the vehicle's identity from other participants. After introducing an identity privacy protection mechanism, the following properties must also be satisfied: First, the correctness of mask cancellation. In DMCFE, each client's mask item is typically bound to its identity or number. If a vehicle hides its number or identity during a task, the mask generation and aggregation decryption processes may be affected, leading to aggregation result offsets or even decryption failure. How to provide participating vehicles with sufficient information to generate a cancelable mask while protecting identity privacy is a pressing issue. Second, identity traceability. While strong anonymity mechanisms can hide a vehicle's true identity, they weaken the system's ability to pinpoint the source of abnormal or malicious data. Conversely, strong traceability mechanisms may re-establish the link between identity and data, thereby undermining the goal of protecting identity privacy. Therefore, how to achieve controllable traceability while protecting vehicle identity privacy is a problem that needs to be solved in vehicle-to-everything (V2X) data sharing.

[0006] Challenge Two: Aggregation Robustness. In the context of connected vehicle data sharing, the reliability of aggregation results highly depends on the reasonableness of the range of participating data. Without an effective data filtering mechanism, abnormal data participating in aggregation can significantly impact the results, potentially misleading applications such as traffic scheduling, safety decisions, and route planning. Existing verifiable DMCFE schemes can verify whether input data or keys are within a specific range and indicate that range proofs can be used for numerical verification, providing a technical approach to solving aggregation robustness. However, achieving aggregation robustness within the DMCFE framework is not a simple data filtering problem. Vehicle-uploaded data is sensitive and is typically always stored in encrypted form; verifying aggregation robustness requires determining whether data values ​​are within a legal range. Therefore, how to verify the reasonableness of the data range and eliminate abnormal data while protecting data privacy is another pressing issue. Summary of the Invention

[0007] To address the aforementioned issues, this invention proposes a privacy-preserving and secure aggregation method for vehicle-to-everything (V2X) data sharing based on DMCFE.

[0008] The technical solution of this invention is as follows: A privacy-preserving and secure aggregation method for vehicle network data sharing based on DMCFE, comprising a data producer, a data requester, an aggregator, a collector, and a blockchain; During the system initialization phase, the data producer generates a long-term key and registers it to the blockchain using an accumulator; During the task distribution phase, the data requester publishes a task to the aggregator, the aggregator constructs the task and sends it to the collector, the data producer obtains the task from the collector, generates an anonymous key and a SOK knowledge signature, and sends it to the collector; The collector performs identity legitimacy verification and feeds back the verification result to the data producer; After identity legitimacy verification, the data collection phase begins, where the data producer generates an encryption key and encrypted data, and uploads a commitment, a scope proof, and encrypted data to the collector; After evidence aggregation and aggregation robustness verification, the collector uploads the vehicle's anonymous public key to the blockchain; The collector generates a participation credential to the data producer; The data producer aggregates the polynomial result calculation mask, uploads a portion of the decryption key to the collector, and the collector uploads the encrypted dataset and a portion of the decryption key set to the aggregator; The aggregator aggregates and decrypts, and uploads the aggregation result to the data requester.

[0009] The task published by the data requester is a data sharing task, defined as follows: ,in, This is a task identifier used to distinguish different data sharing tasks; Indicates the data requester; This indicates the valid time range for the task request data, meaning that the vehicle perception data must be generated within this time range. This indicates the task response deadline. After this time, the system will no longer accept vehicle task responses, and the following conditions must be met: ; Indicates the valid spatial range of the task request data. Including latitude range and longitude range ; This indicates the single shared request type corresponding to this task; Indicates the type of sharing request. The corresponding aggregation operation functions; Indicates the type of sharing request. The corresponding valid range of perceived data; This represents the threshold parameter, which is the minimum number of valid vehicle responses required to complete the task. For data producer vehicles In the task The task response data uploaded is defined as follows: ;in, Indicates vehicle In the mission Temporary identity identifiers used; Indicates the actual data collection time and satisfies ; This indicates the specific location where the vehicle collected the data. and ; This indicates that the vehicle uploads single-dimensional perception data for the current task request type, which meets the requirements. .

[0010] The system initialization phase specifically includes: Step 1.1: Initialize parameters: : based on safety parameters As input, call sequentially , , and The final output system common parameters ; Indicated by safety parameters As input, output common parameters ,in It is a length of prime order Cyclic groups They are two independent generators; Indicated by safety parameters As input, the common parameters of the output accumulator and initial accumulator value ; and It is two lengths prime numbers, and It is also a prime number. , Modulus The quadratic residue group of order is ,and ; Indicated by safety parameters As input, run the safe prime number generation algorithm. get ,in , and and satisfy ;calculate And define the global hash function. Finally, return the common parameters. ; Indicated by safety parameters As input, the generating order is a large prime number. Cyclic group , and and bilinear mapping Define a secure hash function. and and in the group Select two independent generators. and In the group Selecting independent generators Used to generate Pedersen commitments; select two lengths of Generator vectors and ,satisfy ; Final output common parameters ; Step 1.2: Long-term key generation; Encrypt public parameters with public key As input, a private key is randomly selected. And calculate the corresponding public key. The final output key pair ; This represents the administrator's long-term key; This represents the vehicle's long-term key; Represents the long-term key of the data requester; used This represents the collector's long-term key; Step 1.3: The accumulator adds registered vehicles and generates member certificates; Indicates the accumulator common parameters Current accumulator value Elements to be added and the current set of members As input; if Then let and Otherwise, calculate and update the member set. At the same time, During the vehicle registration process, ,when Sometimes, , and The accumulator is maintained by the blockchain through smart contracts. Indicated by common parameters Members and the current set As input, output membership proof , used to prove It is a set The members in, and have been added to the accumulator. middle.

[0011] The task issuance phase specifically includes: Step 2.1, Task Initiation; Data requester generates tasks and using their own long-term private key Sign the task to get The data requester will send the task message. Aggregators that publish data to data sharing platforms; Step 2.2, Task Construction; After receiving the task request, the aggregator uses the data requester's long-term public key. Verify signature This ensures the legitimacy of task requests; the aggregator determines the legitimacy of task requests based on the task. Constraints in Select target area Available collectors within; for each collector Let its coverage area be Then the aggregator selects the set of collectors that meet the conditions. The aggregator will handle the tasks. Forward to the selected collector set Each selected collector Based on threshold parameters Generate a random polynomial locally As the basis for subsequent mask generation, and The collector broadcasts the mission to registered vehicles within its communication coverage area. Step 2.3: Anonymous identity generation; After receiving a task, the vehicle decides whether to respond based on its own status; participating vehicles first generate anonymous key pairs; the anonymous key generation algorithm is denoted as... Its input is a common parameter. long-term public key for administrators Long-term public key of registered vehicles And randomly select an anonymous private key. Vehicle calculation and and order The vehicle outputs the anonymous key pair used in this task. ; Step 2.4: Generation of identity verification certificate; After an anonymous identity is generated for the vehicle, a proof of identity legitimacy, namely a knowledge signature proof, is further generated, denoted as... The common input is Secret Witness The message to be verified is Proof is output by constructing a knowledge signature. The proof relation is expressed as follows: This represents the union operation; Knowledge signature proofs demonstrate, without revealing the vehicle's long-term key, that: first, the vehicle is a legitimate member registered on the platform; and second, the anonymous public key. It was correctly generated by the vehicle, meaning the anonymous private key corresponding to the anonymous public key is known. ,in In the administrator's public key Below The encryption result; third, the message was initiated by a real vehicle holding the long-term private key: knowing the long-term public key. The corresponding long-term private key ;in It is the commitment value constructed during the proof process. It is a random blinding factor. It is a random generator, in order to... The sum is added to the RSA accumulator, introducing an additional random blinding factor. , making It is a prime number; the knowledge signature proof is generated as follows: Select the random mask for accumulator member witnesses. and random mask ,calculate These commitment values ​​are calculated as follows: Calculate the challenge value ,calculate These response values ​​are calculated as follows: The vehicle will Send to the collector, where the proof It consists of the challenge value and response value mentioned above; Step 2.5: Verify identity legitimacy; The vehicle will prove its existence through the above steps. Send to nearby collector RSU The request is to participate in the current task. The set of vehicles currently participating in the task is... , The collector executes the verification algorithm. Used for verification Check the validity of the test result; if it is proven to be valid, output 1; otherwise, output 0 and update the set of vehicles participating in the task. After successful verification, the collector will store the vehicle's anonymous public key. Uploaded to the blockchain for registration, used to synchronize vehicle participation information between different RSU collectors; the specific verification algorithm is as follows: The collector recalculates the commitment value. The specific calculations are as follows: Finally, collector verification .

[0012] The data collection phase specifically includes: Step 3.1: Generate data encryption key; Indicated by common parameters Number of registered vehicles and vector dimension As input, output vehicle encryption key ,in Let the input data be... The weight vector is And the input data and weight vector satisfy ,parameter Meets safety requirements; Step 3.2: Data encryption; Indicated by common parameters Encryption key Vehicle perception data and task identifier As input; calculate the ciphertext ; Step 3.3, Evidence Generation; Vehicle based on perception data Generate commitments encrypt data and its hash value With privacy data Packaged together, As a random blinding factor; vehicle commitment Generate signature ; The vehicle further generates range proof, proof Constructing auxiliary variables and Vehicle certificate The vehicle will and Converted to Bit binary vector , making and Then, merge the two binary vectors into a single vector of length [length missing]. vector , ;make , Each element in is or ,have ; Selecting random blind vectors and random blinding factor Generate vector commitment and Vehicle calculation challenge value and Construct polynomial vectors and Further calculation of the inner product polynomial The constant term satisfies ,and , Vehicle selection random number Calculation coefficient commitment and Calculate the challenge value Substituting the polynomial vector yields and Generate response and Vehicle internal volume proof generates compressed proof. and output data evidence package. ,in ,and ; Step 3.4: Evidence aggregation; After receiving the data evidence uploaded by the vehicles, the collector first aggregates the vehicle's data integrity proof and the scope proof of the perceived data. For BLS signatures, the collector utilizes the homomorphic property of bilinear mappings to compress multiple vehicle signatures into a single aggregated signature. For range proofs, the collector represents the set of commitments submitted by the vehicle as follows: And represent the corresponding range proof set as The collector organizes aggregated evidence. ; Step 3.5: Batch verification; The collector performs batch verification on commitment integrity and scope constraints separately; the collector verifies the integrity of the vehicle commitment signature; for aggregated BLS signatures, the collector checks the equations. Does the equation hold true? If it does, then the commitment value is determined. Unaltered and generated by a legitimate vehicle; the collector performs batch verification of the range proof; the collector first verifies based on... and Translate the commitment to obtain and The collector recalculates the challenge value for each vehicle. , and ,calculate ,in Randomly select batch coefficients for each proof. And according to the proof Restore the corresponding vector state; for Each of them Collector calculation ,in Collector calculation , , as well as ;in Proof by inner product The vector commitment term calculated from the folded proof elements; the collector verifies the equation. If the equation holds true, it means that the perceived data meets the legal range and the vector structure is correct. Step 3.6: Generate vehicle participation certificate; Once both the identity verification evidence and the data verification evidence are verified, the blockchain will recognize the set of vehicles that are validly participating in the current task. , , Anonymous public key Register them and assign them a public serial number. Until the task response deadline Then, all selected collectors A partial participation certificate is generated for each participating vehicle on the blockchain. And uploaded to the blockchain; for vehicles The serial number on the blockchain is collector Off-chain signature generation ,in It is a collector For vehicles The generated polynomial result, It is Encrypted polynomial results, Used to bind task tags and vehicle anonymous public keys; the vehicle first verifies the signature, using... Decrypt the polynomial result, then calculate ; Step 3.7: Partial decryption key generation; Vehicle execution part decryption key generation Indicated by common parameters Data encryption key Polynomial result set and weight As input, the mask is first calculated based on Lagrange interpolation. ,in For Lagrange coefficients; Decryption key for vehicle calculation section ,Will Upload to the collector; Step 3.8: Generate the decryption key and deliver the aggregation result; The collector will anonymously access the vehicle's public key. Partial decryption key With encrypted data After being matched, the decryption keys are sent to the aggregator; the aggregator performs aggregation on all partial decryption keys to obtain the global decryption key. Aggregator calculation ; Step 3.9, Aggregate Decryption; The aggregator executes the decryption algorithm. Aggregator calculation ,calculate and will As the final aggregated decryption result, it is obtained using the data requester's long-term public key. The encrypted data is then submitted to the data requester, and the task is complete. The specific process of aggregation and decryption is as follows: and If the two are identical, they should be eliminated. Step 3.10, Real Identity Tracing Stage; Only the administrator can trace the vehicle's long-term identity; represented as Among them, the vehicle's anonymous public key long-term private key with administrator The administrator calculates based on the ElGamal decryption relationship. This allows the recovery of the vehicle's long-term public key. .

[0013] The beneficial effects of this invention are as follows: In vehicle-to-everything (V2X) data sharing, secure aggregation not only needs to protect the privacy of vehicle perception data, but also needs to verify the legitimacy of participating vehicle identities and that uploaded data is within the legal scope of task constraints. To enhance identity privacy protection, this invention combines ElGamal encryption, a cryptographic accumulator, and knowledge signatures to construct a traceable anonymous identity mechanism, achieving strong identity privacy protection. During the system registration phase, vehicles add their long-term public key to the accumulator, and during the task participation phase, they generate anonymous public keys and prove through knowledge signatures that the anonymous identity was generated by a legitimately registered vehicle. The collector confirms the legitimacy of the vehicle's anonymous identity by verifying the knowledge signature; when a vehicle's anonymous identity is illegitimate or abnormal or invalid data is uploaded, the administrator can restore its real identity based on the anonymous identity, thereby supporting accountability. To achieve state consistency between different collectors, this invention utilizes blockchain to record the verified vehicle anonymous public keys and upload order, providing a basis for subsequent participation credential generation and mask cancellation. Regarding aggregation robustness, this invention employs Pedersen commitments to hide vehicle perception data and combines Bulletproofs range proofs to verify whether the encrypted data meets the legal range requirements specified by the task. This allows for the filtering out of abnormal or significantly off-range data without revealing the plaintext. Finally, the vehicle encrypts the perception data based on DMCFE and uses Lagrange interpolation to generate a masked partial decryption key. This mask is automatically canceled out during the aggregation phase, ensuring the correctness of aggregation decryption under anonymous participation. Although this invention introduces certain overhead for identity legitimacy proofs and range verification, these overheads are necessary security costs for achieving anonymous participation, abnormal data screening, and accountability. Furthermore, the overall computational overhead increases approximately linearly with the number of participating vehicles and the data scale, remaining within an acceptable range. Attached Figure Description

[0014] Figure 1 A model diagram for data sharing in the Internet of Vehicles; Figure 2 This is a flowchart of a privacy-preserving and secure aggregation method for vehicle-to-everything (V2X) data sharing based on DMCFE, as proposed in this invention. Detailed Implementation

[0015] The specific embodiments of the present invention are described below to enable those skilled in the art to better understand the invention. It should be understood that the specific embodiments disclosed herein are for illustrative purposes only and do not constitute a limitation on the scope of protection of the present invention; for those skilled in the art, various equivalent modifications made without departing from the spirit and essence of the present invention should fall within the scope of protection of the present invention. For example... Figure 1As shown, the system of this invention consists of data producers, data requesters, aggregators, collectors, and a blockchain. In the vehicle-to-everything (V2X) scenario, the aggregator is typically a cloud server, responsible for performing aggregation calculations and outputting the final statistical results required for the task. The collector, in the V2X scenario, is an RSU (Resource Unit) and also participates in the system as a full blockchain node, responsible for broadcasting the task to vehicles within its communication coverage area, verifying proofs, and partially organizing the data before forwarding it to the aggregator. The blockchain is used to record and publicly disclose the anonymous public keys of the vehicles participating in the task and their upload order, thereby achieving synchronization of participation information between different collectors.

[0016] To clarify the input structure of the data sharing task and the input structure of the vehicle response task data processed by this invention, this invention provides two definitions: Definition 1 (Data Sharing Task) A data sharing task published by a data requester is defined as follows: in, This is a task identifier used to distinguish different data sharing tasks; This indicates the data requester, such as a navigation service provider or a traffic management center; This indicates the valid time range for the task request data, meaning that the vehicle perception data must be generated within this time range. This indicates the task response deadline. After this time, the system will no longer accept vehicle task responses, and the following conditions must be met: ; This indicates the valid spatial range of the task request data; that is, the vehicle perception data must be generated within a specified road, road segment, or geographical area. Specifically... Including latitude range and longitude range ; This indicates the single type of shared request corresponding to the task, such as average road speed, total vehicle travel time, or average regional temperature. Indicates the type of sharing request. The corresponding aggregation operation functions. This invention mainly uses inner product calculation to achieve aggregation statistics, and can support typical tasks such as weighted summation and average calculation; Indicates the type of share request. The corresponding valid range of perceived data; This represents the threshold parameter, which is the minimum number of valid vehicle responses required to complete the task.

[0017] Definition 2 (Vehicle Response Task Data) for vehicles In the task The task response data uploaded is defined as follows: .in, Indicates vehicle In the mission Temporary identity identifiers used; Indicates the actual data collection time and satisfies ; This indicates the specific location where the vehicle collected the data, where and ; This indicates the single-dimensional perception data uploaded by the vehicle for the current task request type, such as speed, temperature, road segment travel time, or vehicle density, and meets the following requirements: It should be noted that, because the encryption tool used in this invention operates in the integer field, therefore... , , And the corresponding range boundaries are all uniformly encoded and represented as integers before participating in the calculation, that is .

[0018] Figure 2 The overall process of the protocol described in this invention is given, including the system initialization stage, the task issuance stage and the data collection stage.

[0019] System initialization phase; Standard ElGamal encryption is used as an instance of PKE to generate a unique long-term key for each participating entity; simultaneously, an RSA accumulator is used to manage the registered vehicles in the system. At this stage, all participating vehicles have completed registration, and the membership set remains fixed; no new vehicle registrations are accepted during subsequent task execution. The total number of registered vehicles is [number missing]. .

[0020] 1.1 Initialize parameters; The algorithm uses safety parameters As input, call sequentially , , and The final output system common parameters .

[0021] 1) This setting algorithm uses security parameters. As input, output common parameters ,in It is a length of prime order Cyclic groups They are two independent generators.

[0022] 2) This setting algorithm uses security parameters. As input, the common parameters of the output accumulator and initial accumulator value .in, and It is two lengths prime numbers, and It is also a prime number. , Modulus The quadratic residue group, whose order is ,and ; 3) This setting algorithm uses security parameters. As input, run the safe prime number generation algorithm. get ,in , and and satisfy Then calculate And define the global hash function. Finally, it returns common parameters. .

[0023] 4) The algorithm uses safety parameters As input, the generating order is a large prime number. Cyclic group , and and bilinear mapping At the same time, the system defines a secure hash function. and and in the group Select two independent generators. and In the group Selecting independent generators This is used to generate Pedersen commitments. Then, two commitments of length [missing information] are selected. Generator vectors and ,satisfy The final output contains common parameters. .

[0024] 1.2 Long-term key generation; This key generation algorithm encrypts public parameters using a public key. As input, a private key is randomly selected. And calculate the corresponding public key. The final output key pair Each user (including administrators) can invoke this algorithm to generate their long-term key, which we use. This represents the administrator's long-term key. This represents the vehicle's long-term key. This represents the long-term key used by the data requester. This represents the long-term key of the collector.

[0025] 1.3 The accumulator adds registered vehicles and generates member certificates; The addition algorithm uses accumulator common parameters. Current accumulator value Elements to be added and the current set of members As input. If Then let and Otherwise, calculate and update the member set. At the same time, During the vehicle registration process, Therefore when Sometimes, , and The accumulator is maintained by the blockchain via smart contracts.

[0026] The member proves the generation algorithm using common parameters. Members and the current set As input, the algorithm outputs a membership proof. , used to prove It is a set The members in, and have been added to the accumulator. middle.

[0027] Task issuance phase; 2.1 Task Initiation; Data requesters (such as traffic administrators) first generate tasks. and using their own long-term private key Sign the task to get Subsequently, the data requester will send the task message. Aggregators published to data sharing platforms.

[0028] 2.2 Task Construction; After receiving a task request, the aggregator first uses the data requester's long-term public key. Verify signature This is to ensure the legitimacy of the task request. Subsequently, the aggregator, based on the task... Constraints in Select target area The available collectors within. Specifically, for each collector... Let its coverage area be Then the aggregator selects the set of collectors that meet the conditions. Afterwards, the aggregator will handle the task. Forward to the selected collector set Each selected collector Based on threshold parameters Generate a random polynomial locally As the basis for subsequent mask generation, and Finally, the collector broadcasts the mission to registered vehicles within its communication range.

[0029] 2.3 Anonymous identity generation; After receiving a task, the vehicle decides whether to respond based on its own status. The vehicles participating in the task first generate anonymous key pairs. The anonymous key generation algorithm is denoted as... Its input is a common parameter. long-term public key for administrators Long-term public key of registered vehicles And randomly select an anonymous private key. Subsequently, the vehicle calculated... and and order Ultimately, the vehicle outputs the anonymous key pair used in the task. .

[0030] 2.4 Generation of identity verification certificate; After generating an anonymous identity for the vehicle, a proof of identity legitimacy, namely a knowledge signature proof, is further generated. This proof generation algorithm is denoted as... The common input is Secret Witness The message to be verified is The algorithm outputs proof by constructing a knowledge signature. The proof relation can be expressed as follows: This proof demonstrates, without revealing the vehicle's long-term key, that: first, the vehicle is a legitimate member registered on the platform; and second, the anonymous public key... It was correctly generated by the vehicle, meaning that the anonymous private key corresponding to the anonymous public key is known. ,in In the administrator's public key Below The encryption result; third, the message was initiated by a real vehicle holding the long-term private key: knowing the long-term public key. The corresponding long-term private key The knowledge signature proof is generated as follows: Random selection ,as well as Then the commitment value is calculated: Calculate the challenge value Calculate response value Finally, the vehicle will Send to the collector, where the proof It consists of the challenge value and response value mentioned above.

[0031] 2.5 Identity verification; The vehicle will prove its existence through the above steps. Send to nearby RSU collectors The request is to participate in the current task. The set of vehicles currently participating in the task is... , The collector executes the verification algorithm. This algorithm is used for verification. Check the validity of the test result; if it is proven to be valid, output 1; otherwise, output 0 and update the set of vehicles participating in the task. After successful verification, the collector will store the vehicle's anonymous public key. Uploaded to the blockchain registration so that vehicle participation information can be synchronized between different RSU collectors. The specific verification algorithm is as follows: The collector recalculates the following commitment values: Finally, collector verification Data collection phase; 3.1 Data encryption key generation; This encryption key generation algorithm uses public parameters. Number of registered vehicles and vector dimension As input, output vehicle encryption key ,in Let the input data be... The weight vector is And the input data and weight vector satisfy ,parameter It meets security requirements.

[0032] 3.2 Data encryption; The data encryption algorithm uses public parameters. Encryption key Vehicle perception data and task tags As input, we employ the encryption method in the DMCFE scheme based on DCR. We then compute the ciphertext. .

[0033] 3.3 Evidence generation; First, the vehicle uses perception data Generate commitments encrypt data and its hash value With privacy data Packaged together, This is a random blinding factor. Then, the vehicle makes a commitment. Generate signature .

[0034] Further range verification is required for the vehicle. Verification is required. Because Bulletproofs only supports proofs where the value is located in the range of 10 ... Therefore, it needs to be transformed into this form through interval shifting. To do this, an auxiliary variable is constructed. and Vehicles need proof The vehicle will and Converted to Bit binary vector , making and Then, merge the two binary vectors into a single vector of length [length missing]. vector ,therefore .make ,because Each element in is or Therefore, there is Then a random blind vector is selected. and random blinding factor Generate vector commitment and Vehicle calculation challenge value and And based on this, construct a polynomial vector. and Further calculation of the inner product polynomial The constant term satisfies ,and in Vehicle selection random number Calculation coefficient commitment and The challenge value is then calculated. Substituting the polynomial vector yields and Generate response and Finally, the vehicle generates a compressed proof using the inner product proof. and output data evidence package. ,in ,and .

[0035] 3.4 Evidence aggregation; After receiving the data evidence uploaded by the vehicles, the collector first aggregates the vehicle's data integrity proof, and then further aggregates the scope proof of the perceived data. For BLS signatures, the collector utilizes the homomorphic property of bilinear mappings to compress multiple vehicle signatures into a single aggregated signature. For the range proof, the collector represents the set of commitments submitted by the vehicle as follows: And the corresponding range proof set is represented as Ultimately, the collector compiles the aggregated evidence. .

[0036] 3.5 Batch Validation; The collector performs batch verification on commitment integrity and scope constraints separately. First, the collector verifies the integrity of the vehicle commitment signature. For aggregated BLS signatures, the collector checks the equations... Does it hold true? If the equation holds true, then it indicates the commitment value. It has not been tampered with and was generated by a legitimate vehicle. The collector then performs batch verification of the range proof. The collector first verifies based on... and Translate the commitment to obtain and Then, the collector recalculates the challenge value for each vehicle. , and Further calculations ,in Randomly select batch coefficients for each proof. And according to the proof Restore the corresponding vector state. For Each of them Collector calculation ,in Then, the collector calculates... , , as well as .in Proof by inner product The vector commitment term is calculated from the folded proof elements. Finally, the collector verifies the equation. If the equation holds true, it means that the perceived data is within the valid range and the vector structure is correct.

[0037] 3.6 Generation of vehicle participation certificate; Once both the identity verification evidence and the data verification evidence are verified, the blockchain will recognize the set of vehicles that are validly participating in the current task. , , Anonymous public key Register them and assign them a public serial number. Until the task response deadline. Then, all selected collectors A partial participation certificate is generated for each participating vehicle on the blockchain. And uploaded to the blockchain. For vehicles The serial number on the blockchain is collector Off-chain signature generation ,in It is a collector For vehicles The generated polynomial result, It is Encrypted polynomial results, Used to bind task tags and vehicle anonymous public keys. The vehicle first verifies the signature, using... Decrypt the polynomial result, then calculate .

[0038] 3.7 Partial Decryption Key Generation; Vehicle execution part decryption key generation algorithm The algorithm uses common parameters. Data encryption key Polynomial result set and weight As input, the mask is first calculated based on Lagrange interpolation. ,in These are the Lagrange coefficients. Subsequently, the vehicle calculation section decrypts the key. ,Will Upload to the collector.

[0039] 3.8 Generate the decryption key and deliver the aggregation result; The collector will anonymously access the vehicle's public key. Partial decryption key With encrypted data The corresponding decryption keys are then sent to the aggregator. The aggregator aggregates all the partial decryption keys to obtain the global decryption key. Specifically, aggregator computation ; 3.9 Aggregated Decryption; The aggregator executes the decryption algorithm. The aggregator first calculates... Then calculate and will As the final aggregated decryption result, it is obtained using the data requester's long-term public key. The encrypted data is then submitted to the data requester, and the task is complete. The specific process of aggregation and decryption is as follows: and If the two are identical, they should be eliminated. 3.10 Real Identity Tracing Stage; Only the administrator can trace the vehicle's long-term identity. The tracing algorithm is represented as follows: Among them, the vehicle's anonymous public key and the administrator's long-term private key The administrator calculates based on the ElGamal decryption relationship. This allows the vehicle's long-term public key to be recovered. .

Claims

1. A privacy-preserving and secure aggregation method for vehicle-to-everything (V2X) data sharing based on DMCFE, characterized in that, It consists of data producers, data requesters, aggregators, collectors, and a blockchain; data producers generate long-term keys during the system initialization phase and register the long-term keys to the blockchain using an accumulator; During the task distribution phase, data requesters publish tasks to aggregators, aggregators construct tasks to collectors, and data producers obtain tasks from collectors, generate anonymous keys and SOK knowledge signatures to collectors. The collector verifies the legitimacy of the identity and sends the verification result back to the data producer; After identity verification, the data collection phase begins. Data producers generate encryption keys and encrypted data, and upload commitments, scope proofs, and encrypted data to the collector. The collector performs evidence aggregation and aggregation robustness verification, and then uploads the vehicle's anonymous public key to the blockchain. The collector generates participation credentials to the data producers. The data producers aggregate the polynomial result calculation mask, upload a portion of the decryption key to the collector, and the collector uploads the encrypted dataset and a portion of the decryption key set to the aggregator. The aggregator aggregates and decrypts the data, then uploads the aggregated results to the data requester.

2. The privacy-preserving and secure aggregation method for vehicle-to-everything (V2X) data sharing based on DMCFE as described in claim 1, characterized in that, The task published by the data requester is a data sharing task, defined as follows: ,in, This is a task identifier used to distinguish different data sharing tasks; Indicates the data requester; This indicates the valid time range for the task request data, meaning that the vehicle perception data must be generated within this time range. This indicates the task response deadline. After this time, the system will no longer accept vehicle task responses, and the following conditions must be met: ; Indicates the valid spatial range of the task request data. Including latitude range and longitude range ; This indicates the single shared request type corresponding to this task; Indicates the type of sharing request. The corresponding aggregation operation functions; Indicates the type of share request. The corresponding valid range of perceived data; This represents the threshold parameter, which is the minimum number of valid vehicle responses required to complete the task. For data producer vehicles In the task The task response data uploaded is defined as follows: ;in, Indicates vehicle In the mission Temporary identity identifiers used; Indicates the actual data collection time and satisfies ; This indicates the specific location where the vehicle collected the data. and ; This indicates that the vehicle uploads single-dimensional perception data for the current task request type, which meets the requirements. .

3. The privacy-preserving and secure aggregation method for vehicle-to-everything (V2X) data sharing based on DMCFE as described in claim 1, characterized in that, The system initialization phase specifically includes: Step 1.1: Initialize parameters: : based on safety parameters As input, call sequentially , , and The final output system common parameters ; Indicated by safety parameters As input, output common parameters ,in It is a length of prime order Cyclic groups They are two independent generators; Indicated by safety parameters As input, the common parameters of the output accumulator and initial accumulator value ; and It is two lengths prime numbers, and It is also a prime number. , Modulus The quadratic residue group, whose order is ,and ; Indicated by safety parameters As input, run the safe prime number generation algorithm. get ,in , and and satisfy ;calculate And define the global hash function. Finally, return the common parameters. ; Indicated by safety parameters As input, the generating order is a large prime number. Cyclic group , and and bilinear mapping Define a secure hash function. and and in the group Select two independent generators. and In the group Selecting independent generators Used to generate Pedersen commitments; select two lengths of Generator vectors and ,satisfy ; Final output common parameters ; Step 1.2: Long-term key generation; Encrypt public parameters with public key As input, a private key is randomly selected. And calculate the corresponding public key. The final output key pair ; This represents the administrator's long-term key; This represents the vehicle's long-term key; Represents the long-term key of the data requester; used This represents the collector's long-term key; Step 1.3: The accumulator adds registered vehicles and generates member certificates; Indicates the accumulator common parameters Current accumulator value Elements to be added and the current set of members As input; if Then let and Otherwise, calculate and update the member set. At the same time, During the vehicle registration process, ,when Sometimes, , and The accumulator is maintained by the blockchain through smart contracts. Indicated by common parameters Members and the current set As input, output membership proof , used to prove It is a set The members in, and have been added to the accumulator. middle.

4. The privacy-preserving and secure aggregation method for vehicle-to-everything (V2X) data sharing based on DMCFE as described in claim 1, characterized in that, The task issuance phase specifically includes: Step 2.1, Task Initiation; Data requester generates tasks and using their own long-term private key Sign the task to get The data requester will send the task message. Aggregators that publish data to data sharing platforms; Step 2.2, Task Construction; After receiving the task request, the aggregator uses the data requester's long-term public key. Verify signature This ensures the legitimacy of task requests; the aggregator determines the legitimacy of task requests based on the task. Constraints in Select target area Available collectors within; for each collector Let its coverage area be Then the aggregator selects the set of collectors that meet the conditions. The aggregator will handle the tasks. Forward to the selected collector set Each selected collector Based on threshold parameters Generate a random polynomial locally As the basis for subsequent mask generation, and The collector broadcasts the mission to registered vehicles within its communication coverage area. Step 2.3: Anonymous identity generation; After receiving a task, the vehicle decides whether to respond based on its own status; participating vehicles first generate anonymous key pairs; the anonymous key generation algorithm is denoted as... Its input is a common parameter. long-term public key for administrators Long-term public key of registered vehicles And randomly select an anonymous private key. Vehicle calculation and and order ; The vehicle outputs an anonymous key pair for this task. ; Step 2.4: Generation of identity verification certificate; After an anonymous identity is generated for the vehicle, a proof of identity legitimacy, namely a knowledge signature proof, is further generated, denoted as... The common input is Secret Witness The message to be verified is ; Proof output by constructing a knowledge signature The proof relation is expressed as follows: This represents the union operation; The knowledge signature proof proves, without revealing the vehicle's long-term key, that: first, the vehicle is a legitimate member registered within the platform; Second, anonymous public keys It was correctly generated by the vehicle, meaning that the anonymous private key corresponding to the anonymous public key is known. ,in In the administrator's public key Below The encryption result; third, the message was initiated by a real vehicle holding the long-term private key: knowing the long-term public key. The corresponding long-term private key ;in It is the commitment value constructed during the proof process. It is a random blinding factor. It is a random generator, in order to... The sum is added to the RSA accumulator, introducing an additional random blinding factor. , making It is a prime number; the knowledge signature proof is generated as follows: Select the random mask for accumulator member witnesses. and random mask ,calculate These commitment values ​​are calculated as follows: Calculate the challenge value ,calculate These response values ​​are calculated as follows: The vehicle will Send to the collector, where the proof It consists of the challenge value and response value mentioned above; Step 2.5: Verify identity legitimacy; The vehicle will prove its existence through the above steps. Send to nearby collector RSU The request is to participate in the current task. The set of vehicles currently participating in the task is... , The collector executes the verification algorithm. Used for verification Check the validity of the test result; if it is proven to be valid, output 1; otherwise, output 0 and update the set of vehicles participating in the task. After successful verification, the collector will store the vehicle's anonymous public key. Uploaded to the blockchain for registration, used to synchronize vehicle participation information between different RSU collectors; the specific verification algorithm is as follows: The collector recalculates the commitment value. The specific calculations are as follows: Finally, collector verification .

5. The privacy-preserving and secure aggregation method for vehicle-to-everything (V2X) data sharing based on DMCFE according to claim 1, characterized in that, The data collection phase specifically includes: Step 3.1: Generate data encryption key; Indicated by common parameters Number of registered vehicles and vector dimension As input, output vehicle encryption key ,in Let the input data be... The weight vector is And the input data and weight vector satisfy ,parameter Meets safety requirements; Step 3.2: Data encryption; Indicated by common parameters Encryption key Vehicle perception data and task identifier As input; calculate ciphertext ; Step 3.3, Evidence Generation; Vehicle based on perception data Generate commitments encrypt data and its hash value With privacy data Packaged together, As a random blinding factor; vehicle commitment Generate signature ; The vehicle further generates range proof, proof ; Constructing auxiliary variables and Vehicle certificate The vehicle will and Converted to Bit binary vector , making and Then, merge the two binary vectors into a single vector of length [length missing]. vector , ;make , Each element in is or ,have ; Selecting random blind vectors and random blinding factor Generate vector commitment and Vehicle calculation challenge value and Construct polynomial vectors and Further calculation of the inner product polynomial The constant term satisfies ,and , Vehicle selection random number Calculation coefficient commitment and Calculate the challenge value Substituting the polynomial vector yields and Generate response and Vehicle internal volume proof generates compressed proof. and output data evidence package. ,in ,and ; Step 3.4: Evidence aggregation; After receiving the data evidence uploaded by the vehicles, the collector first aggregates the vehicle's data integrity proof and the scope proof of the perceived data. For BLS signatures, the collector utilizes the homomorphic property of bilinear mappings to compress multiple vehicle signatures into a single aggregated signature. For range proofs, the collector represents the set of commitments submitted by the vehicle as follows: And the corresponding range proof set is represented as ; The collector organizes aggregated evidence. ; Step 3.5: Batch verification; The collector performs batch verification on commitment integrity and scope constraints separately; the collector verifies the integrity of the vehicle commitment signature; for aggregated BLS signatures, the collector checks the equations. Does the equation hold true? If it does, then the commitment value is determined. Unaltered and generated by a legitimate vehicle; the collector performs batch verification of the range proof; the collector first verifies based on... and Translate the commitment to obtain and The collector recalculates the challenge value for each vehicle. , and ,calculate ,in Randomly select batch coefficients for each proof. And according to the proof Restore the corresponding vector state; for Each of them Collector calculation ,in Collector calculation , , as well as ;in Proof by inner product The vector commitment term calculated from the folded proof elements; the collector verifies the equation. If the equation holds true, it means that the perceived data meets the legal range and the vector structure is correct. Step 3.6: Generate vehicle participation certificate; Once both the identity verification evidence and the data verification evidence are verified, the blockchain will recognize the set of vehicles that are validly participating in the current task. , , Anonymous public key Register them and assign them a public serial number. Until the task response deadline Then, all selected collectors A partial participation certificate is generated for each participating vehicle on the blockchain. And uploaded to the blockchain; for vehicles The serial number on the blockchain is collector Off-chain signature generation ,in It is a collector For vehicles The generated polynomial result, It is Encrypted polynomial results, Used to bind task tags and vehicle anonymous public keys; The vehicle first verifies the signature, using Decrypt the polynomial result, then calculate ; Step 3.7: Partial decryption key generation; Vehicle execution part decryption key generation Indicated by common parameters Data encryption key Polynomial result set and weight As input, the mask is first calculated based on Lagrange interpolation. ,in For Lagrange coefficients; Decryption key for vehicle calculation section ,Will Upload to the collector; Step 3.8: Generate the decryption key and deliver the aggregation result; The collector will anonymously access the vehicle's public key. Partial decryption key With encrypted data After being matched, the decryption keys are sent to the aggregator; the aggregator performs aggregation on all partial decryption keys to obtain the global decryption key. Aggregator calculation ; Step 3.9, Aggregate Decryption; The aggregator executes the decryption algorithm. Aggregator calculation ,calculate and will As the final aggregated decryption result, it is obtained using the data requester's long-term public key. The encrypted data is then submitted to the data requester, and the task is complete. The specific process of aggregation and decryption is as follows: and If the two are identical, they should be eliminated. Step 3.10, Real Identity Tracing Stage; Only the administrator can trace the vehicle's long-term identity; this is represented as Among them, the vehicle's anonymous public key long-term private key with administrator The administrator calculates based on the ElGamal decryption relationship. This allows the vehicle's long-term public key to be recovered. .

Images