Privacy protection method for data sharing in VANETs based on block chain and reputation mechanism

Abstract

The invention discloses a privacy protection method for data sharing in VANETs based on a block chain and a reputation mechanism, relates to a privacy protection method for data sharing in VANETs, and belongs to the field of privacy protection. The invention provides a privacy protection method for data sharing in VANETs based on a block chain and a reputation mechanism in order to solve the problem that malicious users leak user privacy or inject damaged data and the like in the vehicle data sharing process in existing VANETs. The method comprises the following steps of: 1, respectively initializing a certificate authority (CA), a block chain member, a vehicle user and the reputation of the vehicle user; 2, performing data sharing based on an initialization result in the step 1; 3, reputation feedback is carried out based on data sharing in the step 2; and 4, vehicle reputation updating is carried out based on the reputation score obtained in the step 3.

Description

Technical Field

[0001] The invention relates to a privacy protection method for data sharing in VANETs, ​​and belongs to the field of privacy protection. Background Art

[0002] In VANETs (vehicle ad hoc networks), privacy protection of data sharing is an important research area. Blockchain and reputation mechanism-based methods can effectively solve this problem. However, current research faces some major challenges. First, many schemes rely on centralized storage systems such as cloud servers to manage data storage and sharing through third parties. In practical situations, these third parties are not always trustworthy. They may snoop on users' private data during relevant operations. In addition, centralized storage is vulnerable to problems such as single point failure and denial of service attacks. Second, although these schemes utilize ABE (attribute-based encryption) or other technologies to facilitate fine-grained data access control, methods are usually ignored to determine the trustworthiness of shared objects. In fact, there may be many untrustworthy or even malicious users in dynamic and large-scale IoT environments, who can distribute false data to disrupt the data sharing process or sell shared data for private gain. Cooperating with such users in the data sharing process may lead to the dissemination of inaccurate data or the exposure of user sensitive information. Summary of the invention

[0003] The purpose of the present invention is to solve the problems of malicious users leaking user privacy or injecting damaged data in the process of vehicle data sharing in existing VANETs, ​​and to propose a privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism.

[0004] The specific process of the privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism is as follows:

[0005] Step 1: Certificate authority CA, blockchain member, and vehicle user U i 、Vehicle user U i Initialize the reputation of

[0006] Step 2: Share data based on the initialization result of step 1;

[0007] Step 3: Provide reputation feedback based on the data sharing in step 2;

[0008] Step 4: Update the vehicle reputation based on the reputation score obtained in step 3.

[0009] The beneficial effects of the present invention are:

[0010] 1. Improve data security: The present invention realizes decentralized data storage and sharing by combining blockchain technology, reduces dependence on centralized cloud servers, and thus reduces the risk of single point failure and denial of service attacks.

[0011] 2. Enhanced privacy protection: By utilizing the immutability and transparency of blockchain, the present invention ensures the complete traceability of data flows, while at the same time effectively protecting user privacy by assisting data access control through smart contracts.

[0012] 3. Improve system efficiency: By combining off-chain storage with on-chain indexes, the present invention overcomes the storage limitations of the blockchain itself and makes data management more efficient. In addition, the distributed database stores the data body and only records the data index on the blockchain, making the overall system operation load lighter and data access faster.

[0013] 4. Dynamic reputation scoring mechanism: Introducing a reputation mechanism based on subjective feedback, data providers DO and data users DU can score each other based on their historical behaviors, and the smart contract dynamically updates the user's reputation score. This mechanism ensures the credibility of both parties in the system and punishes malicious users.

[0014] 5. Reduce on-chain computing and storage overhead: The two smart contracts DMSC and RMSC designed and deployed effectively manage user data and reputation information, reducing on-chain computing and storage overhead.

[0015] 6. Improve the robustness of the system: By setting a reputation threshold, the system can automatically revoke malicious users whose reputation is below the threshold, enhancing the system's robustness and anti-attack capabilities.

[0016] 7. Incentive mechanism to promote honest behavior: The present invention encourages users to behave honestly through a reputation mechanism. Honest users can amplify their own reputation and gain more sharing opportunities.

[0017] 8. Enhance the transparency and fairness of data sharing: All data sharing transactions are recorded on the blockchain, ensuring the transparency and fairness of the data sharing process. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is the system model diagram;

[0019] Figure 2 This is the system operation timing diagram. DETAILED DESCRIPTION

[0020] Specific implementation method 1: The specific process of the privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism in this implementation method is as follows:

[0021] Step 1: Certificate authority CA, blockchain member, and vehicle user U i 、Vehicle user U i Initialize the reputation of

[0022] Step 2: Share data based on the initialization result of step 1;

[0023] Step 3: Provide reputation feedback based on the data sharing in step 2;

[0024] Step 4: Update the vehicle reputation based on the reputation score obtained in step 3.

[0025] Specific implementation method 2: This implementation method is different from the specific implementation method 1 in that: in step 1, the certificate authority CA, the blockchain member, and the vehicle user U are respectively i 、Vehicle user U i The reputation is initialized; the specific process is:

[0026] Step 1: Initialize the certificate authority CA; the specific process is as follows:

[0027] Set the safety parameter λ;

[0028] Set the domain F for the certificate authority CA p , and select two prime numbers p and q with digits greater than 128 in the prime field and calculate n = p × q;

[0029] Where n is the modulus, φ(n) = (p-1) × (q-1) is the Euler function;

[0030] For the certificate authority CA, set the long radius of the elliptic curve to a and the short radius to b;

[0031] In the prime domain F p In the example, set the elliptic curve cyclic group G;

[0032] The certificate authority CA selects a point G′ (a point on the curve) in the cyclic group G as a generator of the cyclic group G, so that the order of G′ under the modulus n is φ(n);

[0033] The certificate authority CA is in domain F p A number is randomly selected as the CA's private key sk CA ;

[0034] Based on CA's private key sk CA Calculate the CA's public key pk with the generator G′ CA =sk CA ×G′;

[0035] Step 1 and 2: Initialize blockchain members; the specific process is:

[0036] Step 121: After CA publishes the long radius a and short radius b of the elliptic curve, each blockchain member BM i In the prime domain F p A number is randomly selected as the BM of each blockchain member i Private key

[0037] Based on each blockchain member BM i Private key and generator G′ to calculate each blockchain member BM i The public key

[0038] Where i∈{1,…,N′}, N′ is the total number of blockchain members, and i is the i-th blockchain member;

[0039] Step 122: Each blockchain member BM i Publish your own public key All blockchain members BM start the blockchain ledger L (all blockchain members BM correspond to one ledger);

[0040] Step 1, 2, 3: Each blockchain member BM i Deployed smart contracts RMSC and DMCC;

[0041] Step 13: Vehicle user U i Initialize;

[0042] Step 14: Vehicle user U i Initialize the reputation.

[0043] The other steps and parameters are the same as those in the first embodiment.

[0044] Specific implementation method three: This implementation method is different from specific implementation methods one or two in that: the smart contract RMSC and DMSC in steps one, two and three are specifically:

[0045] 1. Reputation Management Smart Contract RMSC:

[0046] The reputation management smart contract RMSC defines two vehicle user index tables key_List and revo_List;

[0047] key_List is used to record the basic information of vehicle users in the Internet of Vehicles in the blockchain system;

[0048] revo_List is used to record vehicle users in the Internet of Vehicles whose credit scores are lower than the credit threshold;

[0049] The updated reputation score is lower than the blockchain system reputation threshold μT The user will be added to the revo_List and revoked from the network;

[0050] The reputation management smart contract RMSC encapsulates five different functions as follows:

[0051] 1) Init() function:

[0052] If the vehicle user U i In key_List, the vehicle user U i Returns the reputation information of the vehicle user (RS i ,RS T ,N);

[0053] If the vehicle user U i In revo_List, no operation is performed, ending;

[0054] Among them, RS i Represents the vehicle user U i Reputation value, RS T Represents the vehicle user U i The reputation threshold is N, where N represents the number of reputation scores collected within a certain period of time;

[0055] If the vehicle user U i If it is neither in key_List nor in revo_List, then for vehicle user U i Initialization is performed by the vehicle user U i Blockchain member BM i For vehicle users U i Initialize reputation information (RS i ,RS T ,B=1), then add it to key_list;

[0056] The Init() function is for initialization:

[0057] 2) Get_reputation():

[0058] Check vehicle user U i Is it in key_List? If so, return the vehicle user U to the requester. i If not, prompt the requester vehicle user U i Not in the blockchain system;

[0059] Get_reputation() is used to retrieve the reputation value;

[0060] 3) Get_rating():

[0061] Check vehicle user U i Is it in key_List? If so, return the data of vehicle user U in a certain period of time to the data requester. i If not, the data requester vehicle user U is prompted i Not in the blockchain system;

[0062] The Get_rating() is for the vehicle user U i Collect the credit value of the person being rated for a certain period of time:

[0063] 4) Update():

[0064] The Update() is a reputation value update;

[0065] Check vehicle user U i Is it in key_List?

[0066] If the vehicle user U i In key_List, get the vehicle user U i Reputation score RS old and the total number of reputation scores N old (set during initialization and saved in key_list, and the relevant data in key_list will be updated every time it is updated), and then use the Get_rating() function to obtain the vehicle user U i The total number of reputation scores NR harvested in a certain period of time, and the vehicle user U is updated i Reputation score (ID i ,pk i ,N new ,RS new1 ); if RS new1 <μ T Then the vehicle user U i Add revo_List and delete vehicle user U from key_List i All information; if RS new1 ≥μ T Then save the updated result;

[0067] If the vehicle user U i If it is not in key_List, the data requester vehicle user U will be notified i Not in the blockchain system;

[0068] Among them, N old Represents the total number of credit scores before the update, RS old Indicates the credit score before updating;

[0069] N newRepresents the total number of updated reputation scores, RS new1 Indicates the updated reputation score;

[0070] ID i Represents the vehicle user U i Has a unique identification code; pk i Represents the vehicle user U i 's public key;

[0071] NR represents the total number of reputation scores collected by the user from the last update to this update;

[0072] The updated vehicle user U i Reputation score (ID i ,pk i ,N new ,RS new1 ) process is:

[0073] N new =N old +NR

[0074]

[0075] Among them, μ1 represents the reputation update parameter;

[0076] 5) Punish():

[0077] Punish() is used to punish malicious users:

[0078] Check vehicle user U i Is it in key_List?

[0079] If the vehicle user is in U i key_List, then update the vehicle user U i Reputation value RS new2 (Reduce user reputation); if RS new2 <μ T Then the vehicle user U i Add to revo_List and delete the vehicle user ID from key_List i All information; if RS new2 ≥μ T Then save the updated result;

[0080] If the vehicle user U i If it is not in key_List, an error is reported to the requesting vehicle;

[0081] The updated vehicle user U i Reputation value RS new2 The process is:

[0082] RS new2 =RS old ×μ2

[0083] Among them, RS new2 Represents the updated reputation value, RS old represents the reputation value before update, μ2 represents the reputation penalty parameter;

[0084] 2. Data Management Smart Contract DMSC:

[0085] The data management smart contract DMSC uses the geographical location of the vehicle user as an index to create a list index_list to record the address of the vehicle data file in the blockchain;

[0086] The vehicle’s geolocation data is stored as an index to the data itself at the address on the blockchain. Because the data itself is stored in a separate database;

[0087] The data management smart contract DMSC defines a record table called share_list, which is used to record all data sharing transactions between vehicle users in the Internet of Vehicles;

[0088] The data management smart contract DMSC contains three different functions as follows:

[0089] 1) Storage():

[0090] Storage() is used to create an index for the data file in the blockchain;

[0091] (ID i ,pk i ,RS i ,addr,r i ,μ T ) is the input of the Storage() function, and the Get_reputation() function is called to determine the vehicle user U i Is it in key_List and RS i correct;

[0092] If yes, determine the vehicle user U i RS i Is it greater than μ? T ; If so, then the vehicle user U i Join index_list and send BM to blockchain members i Return vehicle user U i The storage address in the blockchain system; if not, the vehicle user U i Add revo_list;

[0093] If not, then send the vehicle user U i Error in returning reputation information;

[0094] Among them, addr is the address where the user data is stored in the database, r i A random number used during data encryption;

[0095] 2) Search():

[0096] Check vehicle user U i Is it in index_list? If so, return the vehicle user U generated by the Storage() function to the data requester. i The storage address in the blockchain system; if not, a message indicating that the search failed is returned to the data requester;

[0097] The Search() is to search for the required storage transaction in the blockchain;

[0098] 3) Share():

[0099] Call Get_reputation() function to determine pk DO and pk DU Are they all in key_List and RS DU >RS T ;

[0100] If so, the data sharing transaction (pk DO ,pk DU ) is recorded in share_list;

[0101] If not, a message indicating data sharing failure is returned to DO and DU;

[0102] Among them, pk DO is the public key of the data owner DO, pk DU is the public key of the data requester DU, RS DU is the reputation value of the data owner DO, RS T is the reputation threshold of the data owner DO;

[0103] Share() is used to record data sharing transactions between users;

[0104] 4) Record():

[0105] Call Get_reputation() function to determine pk DO and pk DU Are they all in key_List and RS DU >RS T ;

[0106] If yes, then the data usage record transaction message msg4 = (ID DU ,ID DO ,PK DU ,PK DO ,RS DU ,kw i ,bool) is recorded in share_list;

[0107] If not, a message indicating data sharing failure is returned to DO and DU;

[0108] Among them, pk DO is the public key of the data owner DO, pk DU is the public key of the data requester DU, ES DU is the reputation score of the data requester DU, RS T is the reputation threshold of the data owner DO;

[0109] Among them, the bool value is 0 or 1, 1 means that DU correctly completes the shared data collection phase and no data leakage occurs, and 0 means that DU leaks DO's private data during the shared data collection phase;

[0110] The Record() is used to record whether data leakage occurs when the user uses the shared data.

[0111] The other steps and parameters are the same as those in the first or second embodiment.

[0112] Specific implementation method 4: This implementation method is different from one of the specific implementation methods 1 to 3 in that: in step 13, the vehicle user U i Initialize; the specific process is:

[0113] Step 131: Each vehicle user U in the Internet of Vehicles i Have a unique ID i ;

[0114] Step 132: Each vehicle user U i In the prime domain F p A number is randomly selected as each vehicle user U i The private key sk i ;

[0115] Based on each vehicle user U i The private key sk i and generator G′ to calculate each vehicle user U i The public key

[0116] Step 133: Each vehicle user U iSend a message to CA via a secure channel (ID i ,pk i );

[0117] CA Verification ID i to ensure that it has not been registered before. If it is unique, the CA generates and sends the user U i Identity certificate Cert i =sign((ID i ,pk i ),sk CA ); if not unique, then user U i Return to User U i identity certificate;

[0118] Among them, ID i For user U i The identity id, sign() is the signature operation using the SHA-256 algorithm;

[0119] Cert i For Cert DO or Cert DU ;

[0120] Cert DO The data owner’s identity certificate, Cert DU The identity certificate of the data requester;

[0121] The CA verification ID i The specific process of uniqueness is:

[0122] CA traverses key_List and checks whether the vehicle user U exists in key_List i ID i , if it exists, it is not unique; if it does not exist, it is unique

[0123] key_List is used to record Internet of Vehicles users;

[0124] In step 14, the vehicle user U i The reputation is initialized; the specific process is:

[0125] Step 141: Vehicle User U i To the blockchain member BM i Submit(ID i ,pk i ,Cert i ), each blockchain member BM i Ensure that the user has completed identity registration;

[0126] Step 142: Call the Init() function in RMSC to establish vehicle user U i Initial reputation information and publicize the vehicle user U on the blockchain i Initial reputation information;

[0127] Reputation information includes reputation score and reputation threshold;

[0128] The reputation score refers to the reputation value of the vehicle user itself in the blockchain system, and the reputation threshold means that when the reputation score of the data requester is greater than the reputation threshold of the vehicle user, the vehicle user will send the data information stored by itself to the requester.

[0129] The other steps and parameters are the same as those in Specific Embodiments 1 to 3.

[0130] Specific implementation method 5: This implementation method is different from any one of the specific implementation methods 1 to 4 in that: in step 2, data sharing is performed based on the initialization result of step 1; the specific process is:

[0131] Step 21: Data storage; the specific process is:

[0132] Step 2: Given data file M i , data file M i Including user information, user location and event type kw i ;

[0133] Event Type kw i is 1, 2, 3, 4, or 5;

[0134] 1 means the road is congested, 2 means the road is damaged, 3 means the road is slippery, 4 means the weather is bad, and 5 means the road is in good condition;

[0135] Blockchain member BM i Use AES symmetric encryption algorithm to encrypt event type kw i Encrypt and obtain the encrypted event type Enc(kw i ), and obtain the key K at the same time;

[0136] Step 2:2. Copy the data file M i Stored in the distributed database, the distributed database returns the data file M i Storage address

[0137] Step 213: Data owner DO sends blockchain member BM i Submit data storage message msg1;

[0138] It is worth noting that RS DO indicates the reputation score of the DO, and RS TIt represents the trust threshold, above which DO considers DU to be trustworthy;

[0139] msg1=(stor_info,sign(stor_info,sk DO ))

[0140] Among them, sign(stor_info,sk DO ) is the message after the storage message stor_info is signed using the SHA-256 algorithm; sk DO The private key of the data owner DO;

[0141] stor_info represents unpacked storage information;

[0142] in

[0143]

[0144] in, For each blockchain member BM i Published own public key; Enc(kw i ) is the encrypted event type; ID DO is the identity id of the data owner DO, pk DO is the public key of the data owner DO, Cert DO is the identity certificate of the data owner DO, r DO It is a random number selected by the data owner DO during the data storage process. For data file M i The storage address of RS DO is the reputation value, RS T is the trust threshold of the data owner DO;

[0145] Step 214: BM i After receiving msg1, BM i Verify the signature and identity certificate Cert DO Correctness;

[0146] If the signature and identity certificate Cert DO Correct, then BM i Package msg1 as a data storage transaction And call the Storage() function in the data management smart contract DMSC to further verify the data storage transaction Correctness of data storage transactions Correct, the data storage transaction is published to the blockchain; if the data storage transaction If it is incorrect, then report the data storage transaction error to DO;

[0147] If the signature and identity certificate Cert DO If it is incorrect, then report the data storage transaction error to DO;

[0148] The BM i Verify the signature and identity certificate Cert DO The specific process of correctness is:

[0149] BM i It traverses key_List and searches for the vehicle user U in key_List i Corresponding BM i Is it BM? i itself, if yes, then the signature and identity certificate Cert DO Correctness; if not, the signature and identity certificate Cert DO Incorrect;

[0150] key_List is used to record Internet of Vehicles users;

[0151] The Storage() function in the data management smart contract DMSC is called to further verify the data storage transaction The correctness process is:

[0152] Check pk according to the storage function DO Is it in key_list, and check RS DO Is it greater than the blockchain system threshold μ? T , if pk DO In key_list and RS DO Greater than the system threshold μ T , data storage transactions Correct, otherwise the data storage transaction is incorrect;

[0153] Step 22: Make a data sharing request for the data stored in step 21; the specific process is as follows:

[0154] The data requester DU uses the Search() function in the DMSC to store the data of the target geographic location. The transaction msg1=(stor_info,sign(stor_info,sk DO )Search in the blockchain;

[0155] If found, the data requester DU evaluates its own reputation score RS DU Is it greater than or equal to the reputation threshold set by the data owner DO? If so, the data requester DU saves the pk of the data storage transaction of the target geographic location. DO , and sends a data sharing request msg2 to the data owner DO, msg2 = (IDDU ,pk DU ,Cert DU ,sign(sk DU )); if not, a request failure message is returned to the data requester DU;

[0156] If the data is not found, an error in the data storage transaction of the target geographic location is reported to the data requester DU;

[0157] Among them, ID DU pk is the identity id of the data requester DU DU is the public key of the data requester DU, Cert DU is the identity certificate of the data requester DU, sign(sk DU ) is to use the SHA-256 algorithm to sign the data request transaction for the data requester DU, sk DU The private key of the data requester DU;

[0158] Step 23: Perform data sharing authorization based on the data sharing request in step 22;

[0159] Step 24: Collect shared data based on the data sharing authorization in step 23;

[0160] Step 25: Generate a feedback token based on the shared data collected in step 24.

[0161] The other steps and parameters are the same as those in Specific Implementation 1 to 4-1.

[0162] Specific implementation method 6: This implementation method is different from the specific implementation methods 1 to 5 in that: in step 23, data sharing authorization is performed based on the data sharing request in step 22; the specific process is:

[0163] Step 231: When the data owner DO receives the sharing request msg2, the data owner DO uses Cert DU Verify whether the data requester DU exists in key_list. If so, execute step 232. If not, report the sharing request msg2 error to the data owner DO.

[0164] If the data requester DU does not receive the feedback message from the data owner DO for a long time, it is determined that the data owner DO has not received msg2, and the data requester DU reports to the data owner DO that the sharing request msg2 is wrong;

[0165] The data owner DO uses Cert DUVerify whether DU exists in the key-list. If so, execute step 232. If not, report the sharing request msg2 error to the data requester DU. The specific process is as follows:

[0166] The data owner DO traverses key_List to find whether the data requester DU exists. If so, it executes step 232; if not, it reports to the data requester DU that the sharing request msg2 is wrong;

[0167] Step 232: The data owner DO calls the Get Reputation() function in the RMSC to determine the reputation score of the DU;

[0168] If the reputation score RS of the data requester DU DU Exceed the reputation threshold RS of the data owner DO T , the data owner DO transmits the key K to DU through the asymmetric encryption RSA algorithm, namely Enc(K);

[0169] If the reputation score RS of the data requester DU DU Does not exceed the reputation threshold RS of the data owner DO T , then report to DU that the sharing request msg2 is wrong;

[0170] The specific process of the data owner DO calling the Get Reputation() function in the RMSC to determine the reputation score of the data requester DU is as follows:

[0171] The data owner DO traverses the key_List to determine whether the data requester DU is in the key_List. If the data requester DU is in the key_List, the data owner DO returns the reputation value of the data requester DU to the data owner DO; if the data requester DU does not exist in the key_List, the data owner DO is reported that the DU does not exist in the key_List;

[0172] Step 233: DO sends a notification to the corresponding BM i Send data sharing message msg3 = (Share_info, sign (Share_info, pk DO ));

[0173] sign() is a signature operation using the SHA-256 algorithm;

[0174] in

[0175] Step 2, 3, 4, BM i After receiving msg3, blockchain member BM i Check the identity certificate Cert DOIf it is correct, then proceed to step 2, 3, and 5; if it is incorrect, then BM i Return the identity certificate Cert to the data owner DO DO mistake;

[0176] The blockchain member BM i Check the identity certificate Cert DO The specific process of correctness is:

[0177] BM i It traverses key_List and searches for the vehicle user U in key_List i Corresponding BM i Is it BM? i If so, the identity certificate Cert DO Correct; if not, then the signature and identity certificate Cert DO Incorrect;

[0178] key_List is used to record Internet of Vehicles users;

[0179] Step 2, 3, 5, Blockchain member BM i Package the shared message msg3 into a data sharing transaction (pk DO ,pk DU ), run the Share() function of DMSC to further check the data sharing transaction (pk DO ,pk DU ) is correct, if correct, then the data sharing transaction (pk DO ,pk DU ); if incorrect, then the blockchain member BM i Return the data sharing transaction (pk DO ,pk DU ) error;

[0180] The Share() function of the DMSC is run to further check the data sharing transaction (pk DO ,pk DU The specific process of the correctness of ) is:

[0181] Call the Get Reputation() function to obtain the reputation information of DO and DU, and compare whether the reputation value of DU is greater than the reputation threshold of DO. If so, the data sharing transaction (pk DO ,pk DU ) is recorded in Share_List, if not, a data sharing failure message is sent to DO and DU;

[0182] The other steps and parameters are the same as those in Specific Implementation Methods 1 to 5-1.

[0183] Specific implementation method 7: This implementation method is different from any one of specific implementation methods 1 to 6 in that: in step 24, shared data collection is performed based on the data sharing authorization in step 23; the specific process is:

[0184] After receiving the authorization message msg3, the data requester DU Mi Request the distributed database for the data stored in DO, and the database returns the encrypted data Enc(kw i );

[0185] The data requester DU uses his own private key sk DU Decrypt the asymmetrically encrypted symmetric key Enc(K) contained in msg3 to obtain the symmetric key K;

[0186] Use the symmetric key K to decrypt the encrypted data Enc(kwi) to obtain the event type kw i ;

[0187] Afterwards, the blockchain member BM to which the data requester DU belongs i Packed message msg4 = (ID DU ,ID DO ,PK DU ,PK DO ,RS DU ,kw i ,bool), use the Record() function to publish the message msg4=(ID DU ,ID DO ,PK DU ,PK DO ,RS DU ,kw i ,bool);

[0188] Among them, the bool value is 0 or 1, 1 means that DU correctly completes the shared data collection phase and no data leakage occurs, and 0 means that DU leaks DO's private data during the shared data collection phase;

[0189] The other steps and parameters are the same as those in Specific Embodiments 1 to 6.

[0190] Specific implementation eight: This implementation differs from any one of specific implementations one to seven in that: in step 25, feedback tokens are generated based on the shared data collection in step 24; the specific process is:

[0191] Note: Both DU and DO need to generate feedback tokens for each other. The token generation principle is the same, only the generation time is different. DU generates feedback token TK after the shared data collection is completed. DUAnd send it to DO. DO generates feedback token TK after receiving the feedback token sent by DU DO and sent to DU;

[0192] Step 251: Blind process:

[0193] After the data requester DU collects the shared data, it sends a data sharing end message TK to the data owner DO. DU , TK DU Feedback token generated for DU;

[0194] Data sharing end message TK DU Perform random blinding and generate a blinded message (TK DU )'; the expression is: (TK DU )′=TK DU ×(G′) r modn;

[0195] Among them, the blinding factor r is a random number;

[0196] BM, the blockchain member to which the data requester DU belongs i The blinded message (TK) is signed using the RSA signature scheme. DU )′ to sign, after the signature is completed, the blockchain member BM i Send the signature σ′ of the blinded message to the data requester DU;

[0197] The signing process is:

[0198] Where σ′ is the signature of the blinded message;

[0199] Step 253: Deblinding process:

[0200] After the user receives the signature σ′ of the blinded message, he deblinds the signature σ′ of the blinded message and recovers the original message TK DU The signature σ of ; the specific process is:

[0201] The user uses his own private key sk DU Unblind the signature σ′ of the blinded message and calculate s = σ′×(pk DU ) - 1 modφ(n), and calculate the final signature σ=s×r -1 modφ(n);

[0202] Among them, s is an intermediate variable.

[0203] The other steps and parameters are the same as those in Specific Implementation 1 to 7-1.

[0204] Specific implementation method 9: This implementation method is different from any one of specific implementation methods 1 to 8 in that: in step 3, reputation feedback is performed based on the data sharing in step 2; the specific process is:

[0205] Step 31: Credibility score generation:

[0206] The data requester DU evaluates the data owner DO based on the msg1 message provided by the data owner DO. The specific process is as follows:

[0207] The blockchain system specifies two types of feedback ratings for the reputation feedback phase: {0, 1},

[0208] Among them, 1 indicates that the msg1 message provided by DO is correct, and 0 indicates that the msg1 message provided by DO is incorrect;

[0209] Use Paillier homomorphic encryption to encrypt the score 0 or 1 to get C i ;

[0210] C i represents the encrypted reputation score;

[0211] Similarly, the data owner DO evaluates the data requester DU based on the bool value in the message msg5 published by the RSU to which the data requester DU belongs in the blockchain; the specific process is:

[0212] The blockchain system specifies two types of feedback ratings for the reputation feedback phase: {0, 1},

[0213] If the bool value is 1, the feedback rating is 1, indicating that the DU has completed the data sharing phase correctly and is trustworthy;

[0214] If the bool value is 0, the feedback rating is 0, indicating that the DU leaked the DO’s private data during the shared data collection phase;

[0215] Step 32: Collect and verify the generated reputation scores; the specific process is as follows:

[0216] Step 321: Collect the generated reputation scores; the specific process is as follows:

[0217] The data owner DO sends the encrypted C i Send to the blockchain member BM i , the message format is:

[0218] msg5=(pk DU ,TK DO ,C i )

[0219] The data requester DU sends the encrypted Ci Send to the blockchain member BM i , the message format is:

[0220] msg6=(pk DO ,TK DU ,C i )

[0221] Among them, C i represents the encrypted reputation score;

[0222] TK DO and TK DU They represent the feedback tokens generated by DO and DU respectively;

[0223] Step 322: Verify the generated credit score; the specific process is as follows:

[0224] The bidirectional verification of DO and DU has the same principle, so we will only use the feedback token of DO verifying DU as an example here;

[0225] Step 3221. Verify feedback token: Use the public keys of DO and DU to verify TK respectively DO and TK DU The specific process is:

[0226] DU sends the deblinded signature σ to DO, and DO uses the blockchain member BM to which DU belongs i The public key of DO verifies the validity of the signature. If it is valid, DO executes step 3222; if it is invalid, BM, the blockchain member to which DO belongs, i Execute step 42;

[0227] The DO uses the blockchain member BM to which the DU belongs. i The process of verifying the validity of the signature using the public key is as follows:

[0228] By calculation and (G′) σ Are they equal? ​​If they are equal, the unblinded signature σ is a valid signature; otherwise, the unblinded signature σ is an invalid signature;

[0229] Step 3222: Decrypt the reputation score:

[0230] BM, the blockchain member to which DO and DU belong i Decrypt C using DO and DU's private keys i After obtaining the score value, it enters the reputation update stage.

[0231] The other steps and parameters are the same as those in Specific Implementation 1 to 8-1.

[0232] Specific implementation method 10: This implementation method is different from any one of specific implementation methods 1 to 9 in that: in step 4, the vehicle reputation is updated based on the reputation score obtained in step 3; the specific process is:

[0233] Reputation Update:

[0234] For the vehicle user U whose feedback token is verified and decrypted successfully i , vehicle user U i Blockchain member BM i Execute the Update() function to update the vehicle user U i Update the reputation value;

[0235] Credit Penalty:

[0236] For vehicle users U whose feedback token verification fails i , vehicle user U i Blockchain member BM i Execute the Punish() function to the vehicle user U i The reputation value is updated.

[0237] The other steps and parameters are the same as those in Specific Implementation Methods 1 to 9.

[0238] This paper proposes a blockchain-based data sharing scheme to achieve secure and efficient data sharing in the Internet of Things. We consider off-chain storage and on-chain indexing strategies to address the storage constraints of blockchain, and design appropriate smart contracts to assist data access control to reduce the computing overhead of Internet of Vehicles users.

[0239] Specifically,

[0240] DOs can periodically store data in a distributed database and upload this data to the blockchain as storage transactions; DUs that require specific data can quickly retrieve and access relevant data through smart contracts; the blockchain will record all data sharing transactions to ensure full traceability of data flows;

[0241] At the same time, a reputation mechanism is introduced in data sharing to measure the credibility of users in the Internet of Vehicles environment;

[0242] The reputation score of the connected car user is derived from the subjective feedback of previous data sharing partners and published on the blockchain;

[0243] Using the solution of the present invention, the DO can set access policies based on reputation scores to specify whether the DU is trustworthy;

[0244] Similarly, DU can measure the reliability of data through the reputation of DO;

[0245] After a data sharing session, both parties can provide each other with reputation feedback based on each other’s behavior during the process; these feedbacks are aggregated over a period of time, and then the smart contract dynamically updates the user’s reputation score;

[0246] Therefore, each user is responsible for the user’s actions during data sharing;

[0247] Honest users can amplify their own reputation and gain more sharing opportunities, while malicious actors face accountability and will be revoked when their reputation falls below the reputation threshold set by the system.

[0248] The present invention designs and deploys two smart contracts, DMSC and RMSC, in the blockchain system to achieve effective management of user data and reputation information with lower on-chain computing and storage overhead.

[0249] The present invention may also have many other embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art may make various corresponding changes and modifications based on the present invention, but these corresponding changes and modifications should all fall within the scope of protection of the claims attached to the present invention.

Claims

1. A privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism, characterized by: The specific process of the method is: Step 1: Certificate authority CA, blockchain member, and vehicle user U i 、Vehicle user U i Initialize the reputation of Step 2: Share data based on the initialization result of step 1; Step 3: Provide reputation feedback based on the data sharing in step 2; Step 4: Update the vehicle reputation based on the reputation score obtained in step 3.

2. The privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism according to claim 1 is characterized by: In step 1, the certificate authority CA, the blockchain member, and the vehicle user U are respectively i 、Vehicle user U i The reputation is initialized; the specific process is: Step 1: Initialize the certificate authority CA; the specific process is as follows: Set the safety parameter λ; Set the domain F for the certificate authority CA p , and select two prime numbers p and q with digits greater than 128 in the prime field and calculate n = p × q; Where n is the modulus, φ(n) = (p-1) × (q-1) is the Euler function; For the certificate authority CA, set the long radius of the elliptic curve to a and the short radius to b; In the prime domain F p In the example, set the elliptic curve cyclic group G; The certificate authority CA selects a point G′ in the cyclic group G as a generator of the cyclic group G, so that the order of G′ under the modulus n is φ(n); The certificate authority CA is in domain F p A number is randomly selected as the CA's private key sk CA ; Based on CA's private key sk CA Calculate the CA's public key pk with the generator G′ CA =sk CA ×G′; Step 1 and 2: Initialize blockchain members; the specific process is: Step 121: After CA publishes the long radius a and short radius b of the elliptic curve, each blockchain member BM i In the prime domain F p A number is randomly selected as the BM of each blockchain member i Private key Based on each blockchain member BM i Private key and generator G′ to calculate each blockchain member BM i The public key Where i∈{1,…,N′}, N′ is the total number of blockchain members, and i is the i-th blockchain member; Step 122: Each blockchain member BM i Publish your own public key pk BMi , all blockchain members BM start the blockchain ledger L; Step 1, 2, 3: Each blockchain member BM i Deployed smart contracts RMSC and DMCC; Step 13: Vehicle user U i Initialize; Step 14: Vehicle user U i Initialize the reputation.

3. The privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism according to claim 2 is characterized by: The smart contracts RMSC and DMSC in steps 1, 2 and 3 are specifically:

1. Reputation Management Smart Contract RMSC: The reputation management smart contract RMSC defines two vehicle user index tables key_List and revo_List; key_List is used to record the basic information of vehicle users in the Internet of Vehicles in the blockchain system; revo_List is used to record vehicle users in the Internet of Vehicles whose credit scores are lower than the credit threshold; The reputation management smart contract RMSC encapsulates five different functions as follows: 1) Init() function: If the vehicle user U i In key_List, the vehicle user U i Returns the reputation information of the vehicle user (RS i ,RS T ,N); If the vehicle user U i In revo_List, no operation is performed, ending; Among them, RS i Represents the vehicle user U i Reputation value, RS T Represents the vehicle user U i The reputation threshold is N, where N represents the number of reputation scores collected within a certain period of time; If the vehicle user U i If it is neither in key_List nor in revo_List, then for vehicle user U i Initialization is performed by the vehicle user U i Blockchain member BM i For vehicle users U i Initialize reputation information (RS i ,RS T , N = 1), and then add it to key_list; The Init() function is for initialization: 2) Get_reputation(): Check vehicle user U i Is it in key_List? If so, return the vehicle user U to the requester. i If not, prompt the requester vehicle user U i Not in the blockchain system; Get_reputation() is used to retrieve the reputation value; 3) Get_rating(): Check vehicle user U i Is it in key_List? If so, return the data of vehicle user U in a certain period of time to the data requester. i If not, the data requester vehicle user U is prompted i Not in the blockchain system; The Get_rating() is for the vehicle user U i Collect the credit value of the person being rated for a certain period of time: 4) Update(): The Update() is a reputation value update; Check vehicle user U i Is it in key_List? If the vehicle user U i In key_List, get the vehicle user U i Reputation score RS old and the total number of reputation scores N old Then use the Get_rating() function to obtain the vehicle user U i The total number of reputation scores NR harvested in a certain period of time, and the vehicle user U is updated i Reputation score (ID i , pk i , N new , R.S. new1 ); if RS new1 <μ T Then the vehicle user U i Add revo_List and delete vehicle user U from key_List i All information; if RS new1 ≥μ T Then save the updated result; If the vehicle user U i If it is not in key_List, the data requester vehicle user U will be notified i Not in the blockchain system; Among them, N old Represents the total number of credit scores before the update, RS old Indicates the credit score before updating; N new Represents the total number of updated reputation scores, RS new1 Indicates the updated reputation score; ID i Represents the vehicle user U i Has a unique identification code; pk i Represents the vehicle user U i 's public key; The updated vehicle user U i Reputation score (ID i , pk i , N new , R.S. new1 ) process is: N new =N old +NR Among them, μ1 represents the reputation update parameter; 5) Punish(): Punish() is used to punish malicious users: Check vehicle user U i Is it in key_List? If the vehicle user is in U i key_List, then update the vehicle user U i Reputation value RS new2 If RS new2 <μ T Then the vehicle user U i Add to revo_List and delete the vehicle user ID from key_List i All information; if RS new2 ≥μ T Then save the updated result; If the vehicle user U i If it is not in key_List, an error is reported to the requesting vehicle; The updated vehicle user U i Reputation value RS new2 The process is: RS new2 =RS old ×μ2 Among them, RS new2 Represents the updated reputation value, RS old represents the reputation value before update, μ2 represents the reputation penalty parameter; 2. Data Management Smart Contract DMSC: The data management smart contract DMSC uses the geographical location of the vehicle user as an index to create a list index_list to record the address of the vehicle data file in the blockchain; The data management smart contract DMSC defines a record table called share_list, which is used to record all data sharing transactions between vehicle users in the Internet of Vehicles; The data management smart contract DMSC contains three different functions as follows: 1) Storage(): Storage() is used to create an index for the data file in the blockchain; (ID i , pk i , R.S. i , addr, ri, μT) is the input of Storage() function, and Get_reputation() function is called to determine the vehicle user U i Is it in key_List and RS i correct; If so, determine the vehicle user U i RS i Is it greater than μ? T ; If so, then the vehicle user U i Join index_list and send BM to blockchain members i Return vehicle user U i The storage address in the blockchain system; if not, the vehicle user U i Add revo_list; If not, then send the vehicle user U i Error in returning reputation information; Among them, addr is the address where the user data is stored in the database, r i A random number used during data encryption; 2) Search(): Check vehicle user U i Is it in index_list? If so, return the vehicle user U generated by the Storage() function to the data requester. i The storage address in the blockchain system; if not, a message indicating that the search failed is returned to the data requester; The Search() is to search for the required storage transaction in the blockchain; 3) Share(): Call Get_reputation() function to determine pk DO and pk DU Are they all in key_List and RS DU >RS T ; If so, the data sharing transaction (pk DO , pk DU ) is recorded in share_list; If not, a message indicating data sharing failure is returned to DO and DU; Among them, pk DO is the public key of the data owner DO, pk DU is the public key of the data requester DU, RS DU is the reputation value of the data owner DO, RS T is the reputation threshold of the data owner DO; Share() is used to record data sharing transactions between users; 4) Record(): Call Get_reputation() function to determine pk DO and pk DU Are they all in key_List and RS DU >RS T ; If yes, then the data usage record transaction message msg4 = (ID DU , ID DO , PK DU , PK DO , R.S. DU ,kw i ,bool) is recorded in share_list; If not, a message indicating data sharing failure is returned to DO and DU; Among them, pk DO is the public key of the data owner DO, pk DU is the public key of the data requester DU, RS DU is the reputation score of the data requester DU, RS T is the reputation threshold of the data owner DO; Among them, the bool value is 0 or 1, 1 means that DU correctly completes the shared data collection phase and no data leakage occurs, and 0 means that DU leaks DO's private data during the shared data collection phase; The Record() is used to record whether data leakage occurs when the user uses the shared data.

4. The privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism according to claim 3 is characterized by: In the step 1-3, the vehicle user U i Initialize; the specific process is: Step 131. Each vehicle user U in the Internet of Vehicles i Have a unique ID i ; Step 132: Each vehicle user U i In the prime domain F p A number is randomly selected as each vehicle user U i The private key sk i ; Based on each vehicle user U i The private key sk i and generator G′ to calculate each vehicle user U i The public key Step 133: Each vehicle user U i Send a message to CA via a secure channel (ID i , pk i ); CA Verification ID i If it is unique, CA generates and sends user U i Identity certificate Cert i =sign((ID i , pk i ), sk CA ); If not unique, then send the i Return to User U i identity certificate; Among them, ID i For user U i The identity id, sign() is the signature operation using the SHA-256 algorithm; Cert i For Cert DO or Cert DU ; Cert DO The data owner’s identity certificate, Cert DU The identity certificate of the data requester; The CA verification ID i The specific process of uniqueness is: CA traverses key_List and checks whether the vehicle user U exists in key_List i ID i , if it exists, it is not unique; if it does not exist, it is unique key_List is used to record Internet of Vehicles users; In step 14, the vehicle user U i The reputation is initialized; the specific process is: Step 141: Vehicle User U i To the blockchain member BM i Submit(ID i , pk i , Cert i ), each blockchain member BM i Ensure that the user has completed identity registration; Step 142: Call the Init() function in RMSC to establish vehicle user U i Initial reputation information and publicize the vehicle user U on the blockchain i Initial reputation information; The reputation information includes a reputation score and a reputation threshold.

5. The privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism according to claim 4 is characterized in that: In step 2, data sharing is performed based on the initialization result of step 1; the specific process is: Step 21: Data storage; the specific process is: Step 2: Given data file M i , data file M i Including user information, user location and event type kw i ; Event Type kw i is 1, 2, 3, 4, or 5; 1 means the road is congested, 2 means the road is damaged, 3 means the road is slippery, 4 means the weather is bad, and 5 means the road is in good condition; Blockchain member BM i Use AES symmetric encryption algorithm to encrypt event type kw i Encrypt and obtain the encrypted event type Enc(kw i ), and obtain the key K at the same time; Step 2:

2. Copy the data file M i Stored in the distributed database, the distributed database returns the data file M i Storage address Step 213: Data owner DO sends blockchain member BM i Submit data storage message msg1; msg1=(stor_info,sign(stor_info,sk DO )) Among them, sign(stor_info, sk DO ) is the message after the storage message stor_info is signed using the SHA-256 algorithm; sk DO The private key of the data owner DO; stor_info represents unpacked storage information; in in, For each blockchain member BM i Published own public key; Enc(kw i ) is the encrypted event type; ID DO is the identity id of the data owner DO, pk DO is the public key of the data owner DO, Cert DO is the identity certificate of the data owner DO, r DO It is a random number selected by the data owner DO during the data storage process. For data file M i The storage address of RS DO is the reputation value, RS T is the trust threshold of the data owner DO; Step 214: BM i After receiving msg1, BM i Verify the signature and identity certificate Cert DO Correctness; If the signature and identity certificate Cert DO Correct, then BM i Package msg1 as a data storage transaction And call the Storage() function in the data management smart contract DMSC to further verify the data storage transaction Correctness of data storage transactions Correct, the data storage transaction is published to the blockchain; if the data storage transaction If it is incorrect, then report the data storage transaction error to DO; If the signature and identity certificate Cert DO If it is incorrect, then report the data storage transaction error to DO; The BM i Verify the signature and identity certificate Cert DO The specific process of correctness is: BM i It traverses key_List and searches for the vehicle user U in key_List i Corresponding BM i Is it BM? i itself, if yes, then the signature and identity certificate Cert DO Correctness; if not, the signature and identity certificate Cert DO Incorrect; key_List is used to record Internet of Vehicles users; The Storage() function in the data management smart contract DMSC is called to further verify the data storage transaction The correctness process is: Check pk according to the storage function DO Is it in key_list, and check RS DO Is it greater than the blockchain system threshold μ? T , if pk DO In key_list and RS DO Greater than the system threshold μ T , data storage transactions Correct, otherwise the data storage transaction is incorrect; Step 22: Make a data sharing request for the data stored in step 21; the specific process is as follows: The data requester DU uses the Search() function in the DMSC to store the data of the target geographic location. The transaction msg1=(stor_info, sign(stor_info, sk DO ))Search in the blockchain; If found, the data requester DU evaluates its own reputation score RS DU Is it greater than or equal to the reputation threshold set by the data owner DO? If so, the data requester DU saves the pk of the data storage transaction of the target geographic location. DO , and sends a data sharing request msg2 to the data owner DO, msg2 = (ID DU , pk DU , Cert DU ,sign(sk DU )); if not, a request failure message is returned to the data requester DU; If the data is not found, an error in the data storage transaction of the target geographic location is reported to the data requester DU; Among them, ID DU pk is the identity id of the data requester DU DU is the public key of the data requester DU, Cert DU is the identity certificate of the data requester DU, sign(sk DU ) is to use the SHA-256 algorithm to sign the data request transaction for the data requester DU, sk DU The private key of the data requester DU; Step 23: Perform data sharing authorization based on the data sharing request in step 22; Step 24: Collect shared data based on the data sharing authorization in step 23; Step 25: Generate a feedback token based on the shared data collected in step 24.

6. The privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism according to claim 5 is characterized by: In step 23, data sharing authorization is performed based on the data sharing request in step 22; the specific process is as follows: Step 231: When the data owner DO receives the sharing request msg2, the data owner DO uses Cert DU Verify whether the data requester DU exists in key_list. If so, execute step 232. If not, report the sharing request msg2 error to the data owner DO. If the data requester DU does not receive the feedback message from the data owner DO for a long time, it is determined that the data owner DO has not received msg2, and the data requester DU reports to the data owner DO that the sharing request msg2 is wrong; The data owner DO uses Cert DU Verify whether DU exists in the key-list. If so, execute step 232. If not, report the sharing request msg2 error to the data requester DU. The specific process is: The data owner DO traverses key_List to find whether the data requester DU exists. If so, it executes step 232; if not, it reports to the data requester DU that the sharing request msg2 is wrong; Step 232: The data owner DO calls the Get Reputation() function in the RMSC to determine the reputation score of the DU; If the reputation score RS of the data requester DU DU Exceed the reputation threshold RS of the data owner DO T , the data owner DO transmits the key K to DU through the asymmetric encryption RSA algorithm, namely Enc(K); If the reputation score RS of the data requester DU DU Does not exceed the reputation threshold RS of the data owner DO T , then report to DU that the sharing request msg2 is wrong; The specific process of the data owner DO calling the Get Reputation() function in the RMSC to determine the reputation score of the data requester DU is as follows: The data owner DO traverses the key_List to determine whether the data requester DU is in the key_List. If the data requester DU is in the key_List, the data owner DO returns the reputation value of the data requester DU to the data owner DO; if the data requester DU does not exist in the key_List, the data owner DO is reported that the DU does not exist in the key_List; Step 233: DO sends a notification to the corresponding BM i Send data sharing message msg3 = (Share_info, sign (Share_info, pk DO )); sign() is a signature operation using the SHA-256 algorithm; in Step 2, 3, 4, BM i After receiving msg3, blockchain member BM i Check the identity certificate Cert DO The correctness of, if correct, then step two, three, five; If incorrect, BM i Return the identity certificate Cert to the data owner DO DO mistake; The blockchain member BM i Check the identity certificate Cert DO The specific process of correctness is: BM i It traverses key_List and searches for the vehicle user U in key_List i Corresponding BM i Is it BM? i If so, the identity certificate Cert Do Correct; if not, then the signature and identity certificate Cert Do Incorrect; key_List is used to record Internet of Vehicles users; Step 2, 3, 5. Blockchain member BM i Package the shared message msg3 into a data sharing transaction (pk DO , pk DU ), run the Share() function of DMSC to further check the data sharing transaction (pk DO , pk DU ) is correct, if correct, then the data sharing transaction (pk DO , pk DU ); if incorrect, then the blockchain member BM i Return the data sharing transaction (pk DO , pk DU ) error; The Share() function of the DMSC is run to further check the data sharing transaction (pk DO , pk DU The specific process of the correctness of ) is: Call the Get Reputation() function to obtain the reputation information of DO and DU, and compare whether the reputation value of DU is greater than the reputation threshold of DO. If so, the data sharing transaction (pk DO , pk DU ) is recorded in Share_List, if not, a data sharing failure message is sent to DO and DU.

7. The privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism according to claim 6 is characterized by: In step 24, shared data collection is performed based on the data sharing authorization in step 23; the specific process is as follows: After receiving the authorization message msg3, the data requester DU Request the distributed database for the data stored in DO, and the database returns the encrypted data Enc(kw i ); The data requester DU uses his own private key sk DU The asymmetrically encrypted symmetric key Enc contained in msg3 (K) Decrypt and obtain the symmetric key K; Use the symmetric key K to encrypt the data Enc(kw i ) to decrypt and get the event type kw i ; Afterwards, the blockchain member BM to which the data requester DU belongs i Packed message msg4 = (ID DU , ID DO , PK DU , PK DO , R.S. DU ,kw i , bool), use the Record() function to publish the message msg4=(ID DU , ID DO , PK DU , PK DO , R.S. DU ,kw i , bool); Among them, the bool value is 0 or 1, 1 means that DU correctly completes the shared data collection phase and no data leakage occurs, and 0 means that DU leaks DO's private data during the shared data collection phase.

8. The privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism according to claim 7 is characterized by: In step 25, feedback token generation is performed based on the shared data collection in step 24; the specific process is: Step 251: Blind process: After the data requester DU collects the shared data, it sends a data sharing end message TK to the data owner DO. DU , TK DU Feedback token generated for DU; Data sharing end message TK DU Perform random blinding and generate a blinded message (TK DU )′; the expression is: (TK DU )′=TK DU ×(G′)Rmodn; Among them, the blinding factor r is a random number; BM, the blockchain member to which the data requester DU belongs i The blinded message (TK) is signed using the RSA signature scheme. DU )′ to sign, after the signature is completed, the blockchain member BM i Send the signature σ′ of the blinded message to the data requester DU; The signing process is: Where σ′ is the signature of the blinded message; Step 253: Deblinding process: After the user receives the signature σ′ of the blinded message, he deblinds the signature σ′ of the blinded message and recovers the original message TK DU The signature σ of ; the specific process is: The user uses his own private key sk DU Unblind the signature σ′ of the blinded message and calculate s = σ′×(pk DU ) -1 modφ(n), and calculate the final signature σ=s×r -1 modφ(n); Among them, s is an intermediate variable.

9. The privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism according to claim 8 is characterized in that: In step 3, reputation feedback is performed based on the data sharing in step 2; the specific process is as follows: Step 31: Credibility score generation: The data requester DU evaluates the data owner DO based on the msg1 message provided by the data owner DO; The specific process is: The blockchain system specifies two types of feedback ratings for the reputation feedback phase: {0, 1}, Among them, 1 indicates that the msg1 message provided by DO is correct, and 0 indicates that the msg1 message provided by DO is incorrect; Use Paillier homomorphic encryption to encrypt the score 0 or 1 to get C i ; C i represents the encrypted reputation score; Similarly, the data owner DO evaluates the data requester DU based on the bool value in the message msg5 published by the RSU to which the data requester DU belongs in the blockchain; the specific process is: The blockchain system specifies two types of feedback ratings for the reputation feedback phase: {0, 1}, If the bool value is 1, the feedback rating is 1, indicating that the DU has completed the data sharing phase correctly and is trustworthy; If the bool value is 0, the feedback rating is 0, indicating that the DU leaked the DO’s private data during the shared data collection phase; Step 32: Collect and verify the generated reputation scores; the specific process is as follows: Step 321: Collect the generated reputation scores; the specific process is as follows: The data owner DO sends the encrypted C i Send to the blockchain member BM i , the message format is: msg5=(pk DU ,TK DO ,C i ) The data requester DU sends the encrypted C i Send to the blockchain member BM i , the message format is: msg6=(pk DO ,TK DU ,C i ) Among them, C i represents the encrypted reputation score; TK DO and TK DU They represent the feedback tokens generated by DO and DU respectively; Step 322: Verify the generated credit score; the specific process is as follows: Step 3221. Verify feedback token: Use the public keys of DO and DU to verify TK respectively DO and TK DU The specific process is: DU sends the deblinded signature σ to DO, and DO uses the blockchain member BM to which DU belongs i The public key of DO verifies the validity of the signature. If it is valid, DO executes step 3222; if it is invalid, BM, the blockchain member to which DO belongs, i Execute step 42; The DO uses the blockchain member BM to which the DU belongs. i The process of verifying the validity of the signature using the public key is as follows: By calculation and (G′) σ Are they equal? ​​If they are equal, the unblinded signature σ is a valid signature; otherwise, the unblinded signature σ is an invalid signature; Step 3222: Decrypt the reputation score: BM, the blockchain member to which DO and DU belong i Decrypt C using DO and DU's private keys i After obtaining the score value, it enters the reputation update stage.

10. The privacy protection method for data sharing in VANETs based on blockchain and reputation mechanism according to claim 9 is characterized in that: In step 4, the vehicle reputation is updated based on the reputation score obtained in step 3; the specific process is: Reputation Update: For the vehicle user U whose feedback token is verified and decrypted successfully i , vehicle user U i Blockchain member BM i Execute the Update() function to update the vehicle user U i Update the reputation value; Credit Penalty: For vehicle users U whose feedback token verification fails i , vehicle user U i Blockchain member BM i Execute the Punish() function to the vehicle user U i The reputation value is updated.

Images