Blockchain-based vehicle identity privacy protection method in internet of vehicles

Abstract

The application discloses a kind of vehicle identity privacy protection methods based on blockchain in Internet of Vehicles, first according to the actual scene in Internet of Vehicles reality, system constructs alliance chain Hyperledger Fabric blockchain network, writes reputation score smart contract in chain code, sets reputation score for each vehicle, manages the reputation score of vehicle in reputation score smart contract, changes the reputation score of vehicle according to the behavior of vehicle;In the communication after vehicle enters, by on-board unit OBU determines which category the message belongs to, whether it needs to be encrypted, for the message that does not need to be encrypted, directly sent to network, and for the message that needs to be encrypted, after being encrypted, sent to specific user by RSU.The application protects vehicle identity privacy from tracking attack, and also prevents vehicle from spreading malicious messages, to establish a safe, reliable and efficient communication environment.

Description

Technical Field

[0001] This invention belongs to the field of blockchain and vehicle network technology, specifically relating to a blockchain-based method for protecting vehicle identity privacy in the Internet of Vehicles. Background Technology

[0002] Currently, the number of connected devices in the Internet of Things (IoT) is growing exponentially. International Data Corporation (IDC) recently predicted that by 2025, 41.6 billion IoT devices will generate 79.4 zettabytes (ZB) of data. Therefore, as more and more smart devices connect to the network, the massive amounts of data generated are vulnerable to cyberattacks during transmission and interaction, leading to data modification or misuse, thus threatening the security of the entire IoT system. The Internet and autonomous vehicles (CAVs) form the backbone of Intelligent Transportation Systems (ITS), providing travel comfort, road safety, and other value-added services. Therefore, in-vehicle ad hoc networks have become a very active topic of discussion in industry and academia. Security is described in the literature as being extremely important in vehicle navigation systems because connected vehicles are directly related to road safety.

[0003] Since Satoshi Nakamoto's team first introduced blockchain technology in 2008, its applications have penetrated various industries. As a decentralized, tamper-proof, and traceable distributed ledger, blockchain is essentially a decentralized distributed ledger database. Simply put, blockchain data is distributed and stored across many nodes in a network. Communication between nodes is not achieved through specific nodes; all nodes can store and update data on the system, thus achieving transparency. This provides significant security for connected vehicles and represents a potential solution for managing vehicle identity privacy.

[0004] The integration of Fabric blockchain and the Internet of Vehicles (IoV) presents a unique challenge in fully realizing the benefits of this integration. Applications based on blockchain technology will further develop the IoV world, particularly addressing issues such as authentication, access control, and data privacy protection between devices and between people and devices. Blockchain technology, with its decentralized nature, can solve the trust and privacy problems faced in the development of the IoV, providing technical support for transparency, distributed storage, and trust, thereby building a secure, reliable, and efficient IoV world. Summary of the Invention

[0005] The purpose of this invention is to provide a blockchain-based method for protecting vehicle identity privacy in the Internet of Vehicles (IoV). This method protects vehicle identity privacy from tracking attacks while also preventing vehicles from spreading malicious messages, thereby establishing a secure, reliable, and efficient communication environment.

[0006] The technical solution adopted in this invention is a blockchain-based vehicle identity privacy protection method in the Internet of Vehicles, which is implemented according to the following steps:

[0007] Step 1: Based on the actual scenarios of connected vehicles, the system constructs a consortium Hyperledger Fabric blockchain network. This network comprises five entities: Vehicle as Client, Road Test Unit (RSU), Member Service Provider (MSP), Trusted Authority (TA), and Certificate Authority (CA). The RSU acts as a sorting node to verify the validity of transactions; the MSP is responsible for verifying the identity of users applying to join the network; the TA acts as an endorsement node, with sufficient space and authority to store data and maintain the ledger; and the CA issues a carNumber to each vehicle entering the network, which, combined with the vehicle's public key, serves as a pseudonym for communication within the network, protecting vehicle privacy. Simultaneously, the CA manages the replacement of vehicle pseudonyms, ensuring vehicle security.

[0008] Step 2: The Member Service Provider (MSP) is responsible for verifying the identity of vehicles joining the network. If the identity is valid, the identity authentication is successful, and the Certificate Authority (CA) issues an authorization certificate to the vehicle. The authorization certificate is stored in the vehicle's local ledger.

[0009] Step 3: Write a reputation score smart contract in the chaincode. The reputation score smart contract is deployed on the Hyperledger Fabric blockchain. Set a reputation score for each vehicle and manage the vehicle's reputation score in the reputation score smart contract. Change the vehicle's reputation score according to the vehicle's behavior.

[0010] Step 4: In the communication after the vehicle enters, the vehicle generates a message, and the on-board unit (OBU) determines which category the message belongs to and whether it needs to be encrypted. Messages that do not need to be encrypted are sent directly to the network, while messages that need to be encrypted are sent to the specific user by the RSU after encryption.

[0011] The invention is further characterized in that,

[0012] Step 1 is implemented in the following steps:

[0013] Hyperledger Fabric permissioned blockchain was chosen as the platform. Hyperledger Fabric is built on Golang. The Hyperledger Fabric 2.0 version was deployed on Ubuntu 1 6.04 to create a blockchain network in the vehicle-to-everything (V2X) scenario. Road test units (RSUs), member service providers (MSPs), trusted authorities (TAs), and certificate authorities (CAs) in the V2X participated as nodes in maintaining the blockchain.

[0014] Step 2 is implemented in the following steps:

[0015] Step 2.1: In cryptography, the elliptic curve is denoted as group G, the generator of group G is denoted as P∈G, and the order of group G is denoted as q. When a vehicle is granted permission to enter the network, vehicle A randomly selects SK from the finite field Zq. A Use it as your private key, and then calculate the public key PK. A =SK A • P, CA randomly generates a unique identifier, carNumber, for each vehicle. This identifier, carNumber, and the vehicle's public key are then used as the vehicle's alias in communication, i.e., PID. A =carNumber||PK A Only the CA knows the true identity of the vehicle, and other users do not know it. This can effectively protect the vehicle's identity privacy. When the authenticity of the messages sent by the vehicle is questioned, the CA needs to arbitrate. At this time, the CA traces the true identity of the vehicle based on the pseudonym information recorded in the local ledger.

[0016] Step 2.2: The vehicle's authorization certificate is issued to the vehicle by the CA and is also stored in the CA's ledger. Even if the vehicle is not in the network, the authorization certificate will not disappear. When the RSU detects that a vehicle is not in the network based on the pseudonym, in order to reduce memory consumption, the RSU will send a request to the CA to revoke the authorization certificate and revoke the expired authorization certificate. The CA will then put the authorization certificate to be revoked into the Certificate Revocation List (CRL). In this way, expired pseudonyms in the network can be deleted. The list shows all the information of the revoked or suspended authorization certificates, with timestamps. If the vehicle's reputation score is lower than the threshold due to misconduct, the pseudonyms owned by the vehicle will be forcibly deleted, including the carNumber.

[0017] Step 3 is implemented in the following steps:

[0018] Step 3.1: When a vehicle joins the blockchain network, the network sets a reputation threshold as the initial reputation value for each vehicle, and also sets a reward coefficient λ and a penalty coefficient β. The reputation score then changes based on the vehicle's performance in the network, with the score increasing or decreasing each time communication occurs.

[0019] Step 3.2: After step 3.1, when vehicle A wants to communicate with vehicle B on the network, vehicle A will attach vehicle B's pseudonym to the message and send it to the RSU. The RSU will then send the encrypted message to vehicle B. Vehicle B obtains A's reputation score from the CA. Based on this score, vehicle B chooses to accept or reject the message. If vehicle B accepts the message without objection, it proves that vehicle A broadcasted genuine information, and vehicle A's reputation score is increased by the CA through a reputation score smart contract. If vehicle B receives the message and objects, the CA arbitrates A's behavior. If the arbitration result shows that vehicle A's behavior is honest, its reputation score will increase; conversely, if the arbitration result shows that vehicle A's behavior is fraudulent, its reputation score will decrease. If vehicle B rejects the communication, vehicle A's reputation score remains unchanged.

[0020] Step 3.3: After step 3.2, based on the arbitration result, CA calculates the vehicle's reputation score. The new reputation score = current reputation score + current reputation score · coefficient, where the coefficient is either a reward coefficient λ or a penalty coefficient β. Vehicle A's reputation score is included in the certificate and updated through a smart contract that modifies the reputation score. In this way, the reputation score is associated with pseudonyms in V2V (vehicle-to-vehicle) and V2I (vehicle-to-infrastructure) communications, incentivizing vehicles to communicate honestly in the network. CA modifies the score according to the reputation score smart contract.

[0021] The smart contract algorithm in step 3.2 is as follows:

[0022] Reputation score change algorithm:

[0023] Input: Transaction type ctx, new grade reputation score, vehicle number carNumber,

[0024] Output: Vehicle ID (carNumber), vehicle parameters;

[0025] Obtain the vehicle status from the chaincode and check if the vehicle is currently on the network;

[0026] Retrieve vehicle information and various vehicle parameters in string format;

[0027] Get the current score of vehicle A; the certificate center arbitrates the behavior of vehicle A based on the records of surrounding vehicles. If the vehicle's behavior is honest, the new credit score = current credit score + current credit score · reward coefficient λ.

[0028] If the vehicle behavior is fraudulent; the new credit score = current credit score + current credit score * penalty coefficient β;

[0029] Then change the score; if the vehicle does not exist, report an error and return the new reputation score.

[0030] Step 4 is implemented in the following steps:

[0031] Step 4.1: In the Internet of Vehicles (IoV), there are two communication methods: V2I (vehicle-to-infrastructure) and V2V (vehicle-to-vehicle). In V2I, messages sent by vehicles are sent directly to the infrastructure. These messages do not involve identity privacy and have a lower message level. In V2V, vehicle messages are first sent to the RSU (Resource Management Unit), and then the RSU sends them to the corresponding vehicle. These messages involve identity privacy and have a higher message level. Message encryption is implemented in smart contracts. After a vehicle generates a message, it first classifies the message. Lower-level messages are forwarded directly after being signed by the vehicle, while higher-level messages are encrypted by an encryption algorithm before being sent to the network.

[0032] Step 4.2: For messages that need to be encrypted, the vehicle uses the SHA256 hash algorithm to hash the RSU's public key PK. RSU Vehicle key SK A , PID A Message m1, timestamp T A Performing logical AND and logical OR operations, the result is represented by two parameters, Q and R, as shown in the following formula:

[0033] Q = H(SK) A ·PK RSU ||PID A ||m1||T A ), R = H(SK) A ·PK RSU ||PK RSU ||T A Let z = Q·SK A v = R·PK RSU The vehicle uses a private key pair M1 = {z, v, PID} A m1, T A After signing, it is sent to the RSU, and the RSU uses its private key SK. RSU Vehicle public key PK A , PID A Message m1, timestamp T A Perform logical AND and logical OR operations, and use Q to express the result. * and R * The two parameters are represented by the formula: Q * =H(SK) RSU ·PK A ||PID A ||m1||T A ), R * =H(SK) RSU ·PK A ||PK RSU||T A ), then let z * =Q * ·PK A v * =R * SK RSU RSU verification of the equation z·P+v=z * +v * Does P hold true, where the base point P, ∈ G is the elliptic curve E? P The addition operations (a, b) form an abelian group G. If the equation holds, RSU calculates C1 = m1 + kPKB and C2 = kP, where PKB is the public key of the target vehicle. Then RSU sets {C1, C2, T} together. A Broadcast to the target vehicle;

[0034] Step 4.3: After step 4.2, the target vehicle receives the encrypted content and calculates C1-SK. B • C2, received the message.

[0035] The smart contract for message encryption in step 4.3 is shown below:

[0036] Message encryption algorithm:

[0037] Input: An unencrypted message;

[0038] Output: An encrypted message;

[0039] The vehicle generates a message; determine the message's level.

[0040] If the message belongs to L1, broadcast it directly.

[0041] If the message belongs to L2 or L3, it is encrypted before being broadcast by the RSU;

[0042] Returns the encrypted message.

[0043] The beneficial effects of this invention are as follows: A blockchain-based vehicle identity privacy protection method in the Internet of Vehicles (IoV) leverages the distributed nature of Hyperledger Fabric to mitigate security issues arising from centralized IoV management. Node pseudonyms ensure identity privacy in the IoV, encryption algorithms guarantee secure message transmission across the network, and digital signatures ensure data integrity and security when vehicle nodes upload transaction data. The Raft consensus mechanism is applied to improve the speed of data transactions. A blockchain copy containing transaction data is ultimately distributed and stored in the RSU (Resource Unit), addressing potential security risks associated with centralized data storage. Reputation scores represent the trustworthiness of vehicles, incentivizing them to honestly execute transactions, thus enabling the entire network to operate securely and efficiently. Attached Figure Description

[0044] Figure 1 This is a system architecture diagram of the blockchain-based vehicle identity privacy protection method in the Internet of Vehicles (IoV) of this invention.

[0045] Figure 2 This is a diagram illustrating the pseudonym issuance process based on Hyperledger Fabric, as simulated by this invention.

[0046] Figure 3 It is aimed at Figure 1 The simulated scenario diagram shows the flowchart of communication between vehicles. Detailed Implementation

[0047] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0048] A blockchain-based method for protecting vehicle identity privacy in the Internet of Vehicles (IoV), combined with Figure 1 As shown, please follow these steps:

[0049] Step 1: Based on the actual scenarios of connected vehicles, the system constructs a consortium Hyperledger Fabric blockchain network. This network comprises five entities: Vehicle as Client, Road Test Unit (RSU), Member Service Provider (MSP), Trusted Authority (TA), and Certificate Authority (CA). The RSU acts as a sorting node to verify the validity of transactions; the MSP is responsible for verifying the identity of users applying to join the network; the TA acts as an endorsement node, with sufficient space and authority to store data and maintain the ledger; and the CA issues a carNumber to each vehicle entering the network, which, combined with the vehicle's public key, serves as a pseudonym for communication within the network, protecting vehicle privacy. Simultaneously, the CA manages the replacement of vehicle pseudonyms, ensuring vehicle security.

[0050] Combination Figures 1-3 Step 1 is implemented in the following steps:

[0051] Hyperledger Fabric was chosen as the platform because it is the first open-source project for consortium blockchains. It uses pluggable components to solve enterprise-level problems. Hyperledger Fabric is built on Golang. The Hyperledger Fabric 2.0 version was deployed on Ubuntu 16.04 to create a blockchain network in a connected vehicle scenario. Roadside Units (RSUs), Member Service Providers (MSPs), Trusted Authorities (TAs), and Certificate Authorities (CAs) in the connected vehicle network participate in maintaining the blockchain as nodes.

[0052] Step 2: The Member Service Provider (MSP) is responsible for verifying the identity of vehicles joining the network. If the identity is valid, the identity authentication is successful, and the Certificate Authority (CA) issues an authorization certificate to the vehicle. The authorization certificate is stored in the vehicle's local ledger.

[0053] Step 2 is implemented in the following steps:

[0054] Step 2.1: In cryptography, the elliptic curve is denoted as group G, the generator of group G is denoted as P∈G, and the order of group G is denoted as q. When a vehicle is granted permission to enter the network, vehicle A randomly selects SK from the finite field Zq. A Use it as your private key, and then calculate the public key PK. A =SK A • P, CA randomly generates a unique identifier, carNumber, for each vehicle. This identifier, carNumber, and the vehicle's public key are then used as the vehicle's alias in communication, i.e., PID. A =carNumber||PK A Only the CA knows the true identity of the vehicle, and other users do not know it. This can effectively protect the vehicle's identity privacy. When the authenticity of the messages sent by the vehicle is questioned, the CA needs to arbitrate. At this time, the CA traces the true identity of the vehicle based on the pseudonym information recorded in the local ledger.

[0055] Step 2.2: The vehicle's authorization certificate is issued to the vehicle by the CA and is also stored in the CA's ledger. Even if the vehicle is not in the network, the authorization certificate will not disappear. When the RSU detects that a vehicle is not in the network based on the pseudonym, in order to reduce memory consumption, the RSU will send a request to the CA to revoke the authorization certificate and revoke the expired authorization certificate. The CA will then put the authorization certificate to be revoked into the Certificate Revocation List (CRL). In this way, expired pseudonyms in the network can be deleted. The list shows all the information of the revoked or suspended authorization certificates, with timestamps. If the vehicle's reputation score is lower than the threshold due to misconduct, the pseudonyms owned by the vehicle will be forcibly deleted, including the carNumber.

[0056] Step 3: Write a reputation score smart contract in the chaincode. The reputation score smart contract is deployed on the Hyperledger Fabric blockchain. Set a reputation score for each vehicle and manage the vehicle's reputation score in the reputation score smart contract. Change the vehicle's reputation score according to the vehicle's behavior.

[0057] Step 3 is implemented in the following steps:

[0058] Step 3.1: When a vehicle joins the blockchain network, the network sets a reputation threshold as the initial reputation value for each vehicle, and sets a reward coefficient λ and a penalty coefficient β. The reputation score then changes based on the vehicle's performance in the network, with the score increasing or decreasing each time communication occurs.

[0059] Step 3.2: After step 3.1, when vehicle A wants to communicate with vehicle B on the network, vehicle A will attach vehicle B's pseudonym to the message and send it to the RSU. The RSU will then send the encrypted message to vehicle B. Vehicle B obtains A's reputation score from the CA. Based on this score, vehicle B chooses to accept or reject the message. If vehicle B accepts the message without objection, it proves that vehicle A broadcasted genuine information, and vehicle A's reputation score is increased by the CA through a reputation score smart contract. If vehicle B receives the message and objects, the CA arbitrates A's behavior. If the arbitration result shows that vehicle A's behavior is honest, its reputation score will increase; conversely, if the arbitration result shows that vehicle A's behavior is fraudulent, its reputation score will decrease. If vehicle B rejects the communication, vehicle A's reputation score remains unchanged.

[0060] Step 3.3: After step 3.2, based on the arbitration result, CA calculates the vehicle's reputation score. The new reputation score = current reputation score + current reputation score · coefficient, where the coefficient is either a reward coefficient λ or a penalty coefficient β. Vehicle A's reputation score is included in the certificate and updated through a smart contract that modifies the reputation score. In this way, the reputation score is associated with pseudonyms in V2V (vehicle-to-vehicle) and V2I (vehicle-to-infrastructure) communications, incentivizing vehicles to communicate honestly in the network. CA modifies the score according to the reputation score smart contract.

[0061] The smart contract algorithm in step 3.2 is as follows:

[0062] Reputation score change algorithm:

[0063] Input: Transaction type ctx, new grade reputation score, vehicle number carNumber,

[0064] Output: Vehicle ID (carNumber), vehicle parameters;

[0065] Obtain the vehicle status from the chaincode and check if the vehicle is currently on the network;

[0066] Retrieve vehicle information and various vehicle parameters in string format;

[0067] Get the current score of vehicle A; the certificate center arbitrates the behavior of vehicle A based on the records of surrounding vehicles. If the vehicle's behavior is honest, the new credit score = current credit score + current credit score · reward coefficient λ.

[0068] If the vehicle behavior is fraudulent; the new credit score = current credit score + current credit score * penalty coefficient β;

[0069] Then change the score; if the vehicle does not exist, report an error and return the new reputation score.

[0070] Step 4: In the communication after the vehicle enters, the vehicle generates a message, and the on-board unit (OBU) determines which category the message belongs to and whether it needs to be encrypted. Messages that do not need to be encrypted are sent directly to the network, while messages that need to be encrypted are sent to the specific user by the RSU after encryption.

[0071] Step 4 is implemented in the following steps:

[0072] Step 4.1: In the Internet of Vehicles (IoV), there are two communication methods: V2I (vehicle-to-infrastructure) and V2V (vehicle-to-vehicle). In V2I, messages sent by vehicles are sent directly to the infrastructure. These messages do not involve identity privacy and have a lower message level. In V2V, vehicle messages are first sent to the RSU (Resource Management Unit), and then the RSU sends them to the corresponding vehicle. These messages involve identity privacy and have a higher message level. Message encryption is implemented in smart contracts. After a vehicle generates a message, it first classifies the message. Lower-level messages are forwarded directly after being signed by the vehicle, while higher-level messages are encrypted by an encryption algorithm before being sent to the network.

[0073] Step 4.2: For messages that need to be encrypted, the vehicle uses the SHA256 hash algorithm to hash the RSU's public key PK. RSU Vehicle key SK A , PID A Message m1, timestamp T A Performing logical AND and logical OR operations, the result is represented by two parameters, Q and R, as shown in the following formula:

[0074] Q = H(SK) A ·PK RSU ||PID A ||m1||T A ), R = H(SK) A ·PK RSU ||PK RSU ||T A Let z = Q·SK A v = R·PK RSU The vehicle uses a private key pair M1 = {z, v, PID} A m1, TA After signing, it is sent to the RSU, and the RSU uses its private key SK. RSU Vehicle public key PK A , PID A Message m1, timestamp T A Perform logical AND and logical OR operations, and use Q to express the result. * and R * The two parameters are represented by the formula: Q * =H(SK) RSU ·PK A ||PID A ||m1||T A ), R * =H(SK) RSU ·PK A ||PK RSU ||T A ), then let z * =Q * ·PK A v * =R * SK RSU RSU verification of the equation z·P+v=z * +v * Does P hold true, where the base point P∈G and G is the elliptic curve E? P The addition operations (a, b) form an abelian group G. If the equation holds, RSU calculates C1 = m1 + kPK. B C2 = kP, where PK B For the public key of the target vehicle, RSU will then use {C1, C2, T} A Broadcast to the target vehicle;

[0075] Step 4.3: After step 4.2, the target vehicle receives the encrypted content and calculates C1-SK. B • C2, received the message.

[0076] The smart contract for message encryption in step 4.3 is shown below:

[0077] Message encryption algorithm:

[0078] Input: An unencrypted message;

[0079] Output: An encrypted message;

[0080] The vehicle generates a message; determine the message's level.

[0081] If the message belongs to L1, broadcast it directly.

[0082] If the message belongs to L2 or L3, it is encrypted before being broadcast by the RSU;

[0083] Returns the encrypted message.

[0084] Protecting vehicle identity privacy effectively reduces the possibility of vehicle identity exposure. A reputation-based incentive mechanism and message encryption are implemented in the smart contract. This approach incentivizes honest vehicle behavior, encourages user participation in network communication, and creates a secure and trustworthy network environment. Messages sent by vehicles are categorized into three levels: information involving identity and other privacy is encrypted before transmission, while general messages do not require encryption. This effectively reduces system load and workload.

[0085] Example

[0086] Step 1: Simulate real-world vehicle-to-everything (V2X) scenarios, such as... Figure 1 As shown, the vehicle network contains several RSUs. Vehicles in the network can communicate with RSUs, and RSUs can also communicate with each other. Data generated during transactions is stored in the consortium blockchain Fabric.

[0087] Step 2: Based on the security requirements for communication over the network, the system assigns aliases to vehicles. For example... Figure 2 The diagram shows the implementation of the corresponding kana issuance;

[0088] Step 2.1, the vehicle sends a request to join the network, such as... Figure 2 As shown in step 2, the request includes the vehicle's public key (PK). A Credit score Rpt A Communication Records List A Timestamp T A The safety factor α is described by the formula Request = (PK A Rpt A List A T A , α);

[0089] Step 2.2: After receiving the request in step 2.1, the MSP first checks if the credit score in the vehicle's transaction records meets the network requirements, and then verifies the vehicle's identity, such as... Figure 2 As shown in step 3;

[0090] Step 2.3: After step 2.2, following the MSP verification, the MSP sends a verification request to the CA, which includes the vehicle's public key (PK). A Credit score Rpt A Communication Records List A Timestamp T A The safety factor α is described as Request = Sig msp(PK A Rpt A List A T A , α), such as Figure 2 As shown in step 4;

[0091] Step 2.4: After step 2.3, once the CA receives the verification certificate, it will first verify the authenticity of the request before sending an authorization certificate to the vehicle. The vehicle certificate is then stored in the local ledger. Figure 2 Steps 5 and 6 are shown in the diagram;

[0092] Step 3, the CA uploads the transaction to the blockchain, such as... Figure 2 As shown in step 7;

[0093] Step 4: There are all kinds of messages in the network. In order to distinguish them, we divide these messages into three levels according to their importance and impact: L1, L2 and L3. Messages with higher levels are encrypted.

[0094] Step 5: Implement message encryption in the smart contract. After the vehicle generates a message, it first categorizes the message. Lower-level messages are forwarded directly after being signed by the vehicle, while higher-level messages are encrypted using an encryption algorithm before being sent to the network. Figure 3 As shown;

[0095] Step 5.1: The OBU determines which level the message belongs to. L1 messages do not need to be encrypted, while L2 and L3 messages are more important and need to be encrypted before forwarding.

[0096] Step 5.2: Messages that do not require encryption can be sent directly to the network, while messages that require encryption are sent to the target vehicle after being encrypted using SHA256.

[0097] Step 5.3: The corresponding vehicle receiving the message decrypts the message and verifies the signature to obtain the message.

Claims

1. A blockchain-based method for protecting vehicle identity privacy in the Internet of Vehicles (IoV), characterized in that, The specific steps are as follows: Step 1: Based on the actual scenarios in the Internet of Vehicles (IoV), the system constructs a consortium Hyperledger Fabric blockchain network. The consortium Hyperledger Fabric blockchain network contains five entities: Vehicle as Client, Road Test Unit (RSU), Member Service Provider (MSP), Trusted Authority (TA), and Certificate Authority (CA). Among them, the Road Test Unit (RSU) acts as a sorting node to verify the validity of transactions; the MSP is responsible for verifying the identity of users applying to join the network. The TA acts as an endorsement node, with ample space and authority to store data and maintain the ledger; the CA issues serial numbers to vehicles entering the network. It is combined with the vehicle's public key to serve as a pseudonym for the vehicle to communicate on the network, in order to protect the vehicle's identity privacy. At the same time, the CA manages the change of the vehicle pseudonym to protect the vehicle's security. Step 2: The Member Service Provider (MSP) is responsible for verifying the identity of vehicles joining the network. If the identity is valid, the identity authentication is successful, and the Certificate Authority (CA) issues an authorization certificate to the vehicle. The authorization certificate is stored in the vehicle's local ledger. Step 3: Write a reputation score smart contract in the chaincode. The reputation score smart contract is deployed on the Hyperledger Fabric consortium blockchain. Set a reputation score for each vehicle and manage the vehicle's reputation score in the reputation score smart contract. Change the vehicle's reputation score according to the vehicle's behavior. Step 3 is implemented in the following steps: Step 3.1: When a vehicle joins the blockchain network, the network sets a reputation threshold as the initial reputation value for each vehicle, and sets a reward coefficient λ and a penalty coefficient β. The reputation score then changes based on the vehicle's performance in the network, with the score increasing or decreasing each time communication occurs. Step 3.2: After step 3.1, when vehicle A wants to communicate with vehicle B on the network, vehicle A will attach vehicle B's pseudonym to the message and send it to the RSU. Then, the RSU will send the encrypted message to vehicle B. Vehicle B obtains vehicle A's reputation score from the CA. Then, vehicle B chooses to accept or reject vehicle A based on its reputation score. If vehicle B accepts the message without raising any objections, it proves that vehicle A broadcasted true information, and vehicle A's reputation score is increased by the CA through the reputation score smart contract. If vehicle B receives the message and raises an objection, then the CA arbitrates vehicle A's behavior. If the arbitration result shows that vehicle A's behavior is honest, then its reputation score will increase; conversely, if the arbitration result shows that vehicle A's behavior is false, then its reputation score will decrease. If vehicle B rejects this communication, then vehicle A's reputation score remains unchanged. Step 3.3: After step 3.2, based on the arbitration result, CA calculates the reputation score for vehicle A. The new reputation score = current reputation score + current reputation score • coefficient, where the coefficient is either a reward coefficient λ or a penalty coefficient β. Vehicle A's reputation score is included in the certificate and updated through a smart contract that modifies the reputation score. In this way, the reputation score is associated with pseudonyms in V2V (vehicle-to-vehicle) and V2I (vehicle-to-infrastructure) communications, incentivizing vehicles to communicate honestly in the network. CA modifies the score according to the reputation score smart contract. Step 4: In the communication after the vehicle enters, the vehicle generates a message, and the on-board unit (OBU) determines which category the message belongs to and whether it needs to be encrypted. Messages that do not need to be encrypted are sent directly to the network, while messages that need to be encrypted are sent to specific users by the RSU after encryption. Step 4 is implemented in the following steps: Step 4.1: In the Internet of Vehicles (IoV), there are two communication methods: V2I (vehicle-to-infrastructure) and V2V (vehicle-to-vehicle). In V2I, messages sent by vehicles are sent directly to the infrastructure. These messages do not involve identity privacy and have a lower message level. In V2V, vehicle messages are first sent to the RSU (Resource Management Unit), and then the RSU sends them to the corresponding vehicle. These messages involve identity privacy and have a higher message level. Message encryption is implemented in smart contracts. After a vehicle generates a message, it first classifies the message. Lower-level messages are forwarded directly after being signed by the vehicle, while higher-level messages are encrypted by an encryption algorithm before being sent to the network. Step 4.2: For messages that need to be encrypted, the vehicle uses the SHA256 hash algorithm to hash the RSU's public key. Vehicle private key ,pseudonym ,information timestamp Performing logical AND and logical OR operations, the result is represented by two parameters, Q and R, as shown in the following formula: , , and then , Vehicle uses private key pair After signing, it is sent to the RSU, and the RSU uses its private key. Vehicle public key ,pseudonym ,information timestamp Perform logical AND and logical OR operations, and use the result in... and The two parameters are represented by the formula: , , and then , RSU verification equation Whether it holds true, where the base point P∈G, and G is an elliptic curve. Addition operations form an abelian group G, where a and b represent random numbers in a finite field. If the equation holds, RSU is calculated. , ,in The public key of the target vehicle. This indicates the private key of vehicle B, and then the RSU will... Broadcast to the target vehicle; Step 4.3: After step 4.2, the target vehicle receives the encrypted content and calculates... The message was obtained.

2. The method for protecting vehicle identity privacy based on blockchain in the Internet of Vehicles according to claim 1, characterized in that, Step 1 is implemented in the following steps: The Hyperledger Fabric blockchain was chosen as the platform for construction. Hyperledger Fabric is built on Golang, and the Hyperledger Fabric 2.0 version was deployed on Ubuntu 16.04 to create a blockchain network in the vehicle-to-everything (V2X) scenario. Road test units (RSUs), member service providers (MSPs), trusted authorities (TAs), and certificate authorities (CAs) in the V2X participated as nodes in maintaining the blockchain.

3. The method for protecting vehicle identity privacy based on blockchain in the Internet of Vehicles according to claim 2, characterized in that, Step 2 is implemented in the following steps: Step 2.1: In cryptography, the system selects an elliptic curve group denoted as G. Group G is an abelian group composed of elliptic curve E and mod p additions. The generator of group G is denoted as P∈G, where P is a base point in the abelian group G. The order of group G is denoted as q. When a vehicle is granted permission to enter the network, it randomly selects SK from the finite field Zq. A Use it as your private key, then calculate the public key. The CA randomly generates a unique identifier, carNumber, for each vehicle. This carNumber, along with the vehicle's public key, then serves as a pseudonym for the vehicle in communications. Only the CA knows the true identity of the vehicle, and other users do not know it. This can effectively protect the vehicle's identity privacy. When the authenticity of the messages sent by the vehicle is questioned, the CA needs to arbitrate. At this time, the CA traces the true identity of the vehicle based on the pseudonym information recorded in the local ledger. Step 2.2: The vehicle's authorization certificate is issued to the vehicle by the CA and is also stored in the CA's ledger. Even if the vehicle is not in the network, the authorization certificate will not disappear. When the RSU detects that a vehicle is not in the network based on the pseudonym, in order to reduce memory consumption, the RSU will send a request to the CA to revoke the authorization certificate and revoke the expired authorization certificate. The CA will then put the authorization certificate to be revoked into the Certificate Revocation List (CRL). In this way, expired pseudonyms in the network can be deleted. The list shows all the information of the revoked or suspended authorization certificates, with timestamps. If the vehicle's reputation score is lower than the threshold due to misconduct, the pseudonyms owned by the vehicle will be forcibly deleted, including the carNumber.

4. The method for protecting vehicle identity privacy based on blockchain in the Internet of Vehicles according to claim 3, characterized in that, The smart contract algorithm in step 3.2 is as follows: Reputation score change algorithm: Input: Transaction type ctx New value of credit score newgrade Vehicle number carNumber ; Output: Vehicle number carNumber Vehicle parameters; Obtain the vehicle status from the chaincode and check if the vehicle is currently on the network; Retrieve vehicle information and various vehicle parameters in string format; Get the current score of vehicle A; The certificate center arbitrates vehicle A's behavior based on the records of surrounding vehicles. If the vehicle's behavior is honest, the new credit score = current credit score + current credit score • reward coefficient λ. If the vehicle behavior is fraudulent; the new credit score = current credit score + current credit score • penalty coefficient β; Then change the score; if the vehicle does not exist, report an error and return the new reputation score.

5. The method for protecting vehicle identity privacy based on blockchain in the Internet of Vehicles according to claim 4, characterized in that, The smart contract for message encryption in step 4.3 is shown below: Message encryption algorithm: Input: An unencrypted message; Output: An encrypted message; The vehicle generates a message; determine the message's level. If the message belongs to L1, broadcast it directly. If the message belongs to L2 or L3, it is encrypted before being broadcast by the RSU; L1 indicates that the message is at level 1, L2 indicates that the message is at level 2, and L3 indicates that the message is at level 3. Returns the encrypted message.

Images