A vehicle privacy protection method based on a cloud storage block chain in a vehicle networking

Abstract

The present application relates to the technical field of blockchain application such as decentralized identity management, and particularly relates to a vehicle privacy protection method based on cloud storage blockchain in Internet of Vehicles, which comprises the following steps: a vehicle is registered to a cloud network, and the cloud network generates a permanent identity and a temporary identity for the vehicle after the registration is successful; when vehicle A needs to interact with other vehicles, vehicle A sends its temporary identity to the cloud and applies for a verifiable claim; the cloud creates the verifiable claim and feeds back to vehicle A, and the verifiable claim includes the validity period of the temporary identity Track ID; after receiving the verifiable claim, if vehicle A needs to request to interact with vehicle B, vehicle A sends the verifiable claim and the interaction request to vehicle B; vehicle B verifies the validity of the verifiable claim through the public key of the cloud system, and if the verification is passed, vehicle B accepts the interaction request, otherwise, vehicle B rejects the interaction request; the present application can effectively guarantee the identity security of the vehicle.

Description

Technical Field

[0001] This invention relates to technologies in the field of blockchain applications such as decentralized identity management, and specifically to a method for protecting vehicle privacy in the Internet of Vehicles based on cloud-stored blockchain. Background Technology

[0002] Blockchain technology is a technology based on decentralized, distributed databases. In a blockchain network, data is divided into many "blocks" and "linked" together to form a "chain." Each block is designed to contain all the information from the previous block, facilitating information verification, recording, and traceability. The greatest advantage of blockchain technology is its decentralization; it does not require a single institution or intermediary for authentication and verification. This means that data is not stored in a single central database but on many distributed nodes, and the entire network can continue to operate even if some nodes are attacked or fail.

[0003] Decentralized Identifiers (DIDs) are a blockchain-based identity authentication and authorization solution that allows users to create unique digital identifiers on the blockchain, with users having full control over their private keys and data. These digital identifiers can be used to verify user identity without the need for a centralized identity verification authority.

[0004] The Internet of Vehicles (IOV) is a vehicle network that enables interconnection between vehicles, between vehicles and road infrastructure, and between vehicles and the internet, facilitating data exchange and information sharing. The IOV primarily consists of two parts: the cloud server and the on-board unit (OBU). The cloud server (CS) is the core component of the IOV system and the primary location for data storage and computation. Vehicle data is centrally managed, analyzed, and processed on the CS, providing various services to vehicle owners and service providers. The on-board unit (OBU) is installed in the vehicle's embedded devices, including sensors and communication modules. Its main responsibility is to collect and upload vehicle data, while also receiving instructions from the CS to complete corresponding operations.

[0005] In the existing connected vehicle ecosystem, cloud-based customer service (CS) generally adopts a centralized model. Each automaker builds its own cloud server and provides services for its own brand of vehicles. There is no unified platform between automakers or between automakers and third-party institutions such as the government, making it impossible to achieve cross-platform data sharing.

[0006] Furthermore, identity management in the connected vehicle ecosystem is currently primarily handled by centralized Certificate Authorities (CAs). CAs issue identity certificates to vehicles and complete identity authentication through certificate exchange and verification. Due to the rapid mobility and frequent information exchange of vehicles, using certificates for identity authentication makes it vulnerable to attackers tracking vehicle movements and cracking identities, thereby threatening the vehicle's location and identity privacy information. Summary of the Invention

[0007] To address the issue of overly centralized cloud-based identity authentication and authorization methods in the existing connected vehicle ecosystem, this invention proposes a vehicle privacy protection method based on cloud-based blockchain storage. This method constructs a cloud system based on blockchain technology, comprising multiple cloud nodes and a blockchain. Vehicles authenticate their identities through these cloud nodes. Figure 6 Specifically, it includes the following steps:

[0008] The vehicle registers with the cloud network. After successful registration, the cloud network generates a permanent identity and a temporary identity for the vehicle.

[0009] When vehicle A needs to interact with other vehicles, vehicle A sends its temporary identity to the cloud and requests a verifiable claim from it;

[0010] A verifiable claim is created in the cloud and fed back to vehicle A. The verifiable claim includes the validity period of the temporary identity Track ID.

[0011] After receiving the verifiable statement, if vehicle A needs to request interaction with vehicle B, it will send the verifiable statement and interaction request to vehicle B.

[0012] Vehicle B can verify the validity of the claim through the public key verification of the cloud system. If the verification is successful, it will accept the interaction request from Vehicle A; otherwise, it will reject it.

[0013] Furthermore, the vehicle's own identity information is a decentralized identity created by the on-board unit based on the Vehicle Identification Number (VIN). The decentralized identity includes a DID identifier, a DID public-private key pair, and a DID document. The DID identifier is a string of digital identity, and the DID document stores the information of the DID identifier and the DID public-private key pair. One DID identifier corresponds to one DID document.

[0014] Furthermore, the DID identifier is obtained by converting the vehicle's VIN code into ciphertext using a random encryption algorithm. In other words, the VIN code cannot be deduced from the DID identifier, nor can the DID identifier be deduced from the VIN code.

[0015] Furthermore, the data structure of a DID document is represented as {id, created, updated, publicKey, proof}, where id stores the DID identifier, created stores the time the DID document was created, updated stores the time the DID document was maintained, publicKey stores the vehicle public key information associated with the current DID document, and proof stores the proof of the current DID document.

[0016] Furthermore, when a vehicle applies for a verifiable declaration to the cloud, if the vehicle is not currently registered in the vehicle network, the registration process includes the following steps:

[0017] Vehicles that need to be registered send their DID identifier and DID document, signed with their own private key, to the nearest cloud node.

[0018] The cloud node that receives the registration request will send the request to other cloud nodes in the blockchain network via P2P encrypted communication.

[0019] All cloud nodes that receive the registration request information verify the signature using the public key in the DID document to verify whether the request comes from the correct sender and has not been tampered with. If the verification fails, the vehicle registration request is rejected.

[0020] If the verification is successful, each cloud node queries the DID identifier in the blockchain network to verify whether the DID has been registered. If it has been registered, the vehicle registration request is rejected.

[0021] If no registration is made, each node in the cloud will vote on the registration request through a consensus protocol. Each node has only one vote and can only vote for either allowing or rejecting registration. The node with the most votes of each voting type within the specified time will be the voting result.

[0022] If the voting result is to reject registration, the cloud node that initially received the registration request message will send back a message rejecting registration.

[0023] If the voting result allows registration, each cloud node uses the private key of the cloud system to sign the DID document. This signature serves as proof of the DID document; that is, the signature is written into the proof field of the DID document to prove that the DID has been verified.

[0024] Each cloud node uses a digest algorithm to generate a temporary identity Track ID corresponding to the DID identifier. Each cloud node then packages the Track ID, DID identifier, and DID document into a block.

[0025] Cloud nodes use a consensus protocol to vote on blocks, broadcast the hash of the packaged block to other cloud nodes, and receive the block hashes sent by other cloud nodes, comparing them with the hash of their own packaged blocks.

[0026] If the hash of the block packaged independently by each cloud node is the same as that of the majority of other cloud nodes, the vote is considered to have passed, and the block can be added to the blockchain. The cloud node that initially received the request will sign the DID document and Track ID using the private key of the cloud system and send them back to the vehicle.

[0027] Otherwise, the node that initially received the request sends a rejection message. After successful vehicle registration, the cloud system's public key is made public to the vehicle. Upon receiving the rejection message, the vehicle verifies the validity of the signature using the cloud's public key. After verifying the signature, the DID document and Track ID are stored locally, with the DID document serving as the vehicle's permanent identity and the Track ID serving as the vehicle's temporary identity.

[0028] Furthermore, the Track ID, DID identifier, and DID document are packaged into a block. In its block structure, the DID identifier and Track ID are recorded in the ID list of the block header, and the DID document is recorded as a data record in the block body.

[0029] Furthermore, each vehicle's temporary Track ID has an expiration date and needs to be updated periodically. The update process includes:

[0030] A new temporary identity (hereinafter referred to as new Track ID) is generated by combining the vehicle's driving data during the validity period of the current temporary identity with the digest generation algorithm;

[0031] The vehicle uses the private key corresponding to the DID document to sign the DID identifier and the new Track ID, and packages the DID identifier, new Track ID, driving data and signature information into a temporary identity update request and sends it to the nearest cloud node;

[0032] After receiving the temporary identity update request, the cloud node will send the request to other cloud nodes via P2P encrypted communication;

[0033] The cloud node queries the DID document in the blockchain network based on the DID identifier, verifies the signature based on the public key in the DID document, and verifies whether the request comes from the correct sender and has not been tampered with. If the verification fails, the vehicle's request is rejected.

[0034] The cloud node uses the vehicle's current Track ID stored in the blockchain network and performs the same digest algorithm as the vehicle on the driving data uploaded by the vehicle. The result is compared with the new Track ID to verify whether the vehicle has uploaded forged data. If the verification fails, the vehicle's request is rejected.

[0035] Cloud nodes use a consensus protocol to vote on update requests. Each cloud node has one vote and only two types of votes: agree to update or reject update. The option that receives the most votes within a specified time becomes the voting result. If the voting result is to reject update, the node that first received the request will send a message rejecting update.

[0036] If the voting result allows the update, the cloud node generates a verifiable claim based on the new Track ID. The cloud node signs the verifiable claim using the system private key. This signature serves as proof of the verifiable claim. That is, the signature is written into the proof field of the verifiable claim, proving that the new Track ID and the corresponding verifiable claim have been verified.

[0037] The cloud node packages the Track ID, new Track ID, and generated verifiable claim into a block. The Track ID and new Track ID are recorded in the ID list in the block header, and the verifiable claim is recorded as a piece of data in the block body.

[0038] Each node votes on the block through the consensus protocol, broadcasts the hash of the packaged block to the other nodes, and receives the block hashes sent by the other nodes and compares them with the hash of its own packaged block.

[0039] If the hash of the block packaged independently by each node is the same as that of the majority of other nodes, the vote is considered to have passed, and the block can be added to the blockchain. The cloud node that initially received the temporary identity update request will send the verifiable statement back to the vehicle after signing it with the system private key.

[0040] If the vote fails, the cloud node that initially received the temporary identity update request sends a rejection message.

[0041] Furthermore, the data structure of a verifiable claim is represented as {id, issuanceDate, expirationDate, publicKey, dataHsah, proof}, where id stores the vehicle's current temporary identity Track ID, issuanceDate stores the issuance time of the current verifiable claim, expirationDate stores the expiration time of the current verifiable claim, publicKey stores the DID public key of the vehicle associated with the current verifiable claim, dataHsah stores the driving data digest corresponding to the Track ID associated with the current verifiable claim, and proof stores the proof of the current verifiable claim.

[0042] Furthermore, the process of generating a new temporary identity, new Track ID, by combining the vehicle's driving data during the current temporary identity's validity period with a digest generation algorithm includes:

[0043] The vehicle uses the Track ID generated by the digest algorithm in the previous cycle as the first data digest;

[0044] A driving data digest corresponding to the driving data is generated using a digest algorithm, which serves as the second data digest, and the first and second data digests have the same length.

[0045] The first and second data summaries are joined together by aggregation, and the concatenated data is used to generate a third data summary using a digest algorithm.

[0046] Use the third data digest as the new Track ID.

[0047] Compared with the prior art, the present invention has the following beneficial effects:

[0048] 1) This invention proposes a novel vehicle identity management method. By using decentralized identity (DID) and temporary identities, it achieves conditional vehicle privacy protection. The decentralized identity identifier and related information are autonomously controlled by the vehicle and protected by a key, ensuring that it can only be used by the correct holder and preventing impersonation. The vehicle's decentralized identity is only used when interacting with the cloud and is not publicly disclosed, reducing the risk of identity leakage. Temporary identities can be publicly disclosed, but because they do not contain vehicle information and the vehicle's decentralized identity cannot be inferred from the temporary identity, vehicle identity security is guaranteed.

[0049] 2) This invention also proposes a cloud-based client-server architecture based on blockchain technology. By using a decentralized distributed node mechanism, it effectively solves the problem of excessive centralization of the cloud in the traditional vehicle networking ecosystem. Simultaneously, it fully leverages the advantages of decentralization, achieving tamper-proof and persistent storage to ensure data security, while also achieving high availability and high fault tolerance. Even if some nodes fail, data storage and management will not be affected. Furthermore, the cloud nodes are composed of cloud servers belonging to various automakers, and the information stored in the cloud is visible to all nodes, facilitating cross-automaker identity query and authentication.

[0050] 3) This invention also proposes a data management method based on driving data to generate temporary identities, store data digests on-chain, and store complete data off-chain. By using a blockchain structure to protect data digests, using a distributed database to store driving data, and highly associating driving data with data digests, the method achieves the purpose of storing vehicle driving data while increasing the difficulty for attackers to maliciously crack temporary identity verification, thus protecting vehicle data and privacy security. Attached Figure Description

[0051] Figure 1 This is a diagram of the cloud architecture based on a blockchain structure proposed in this invention;

[0052] Figure 2 A field structure diagram of the DID document provided by this invention;

[0053] Figure 3 The blockchain structure diagram provided for this invention;

[0054] Figure 4 A field structure diagram of the block header provided by this invention;

[0055] Figure 5 A field structure diagram of the verifiable declaration VC provided by this invention;

[0056] Figure 6 This is a flowchart illustrating a vehicle privacy protection method based on cloud storage blockchain in the Internet of Vehicles according to the present invention. Detailed Implementation

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

[0058] This invention proposes a vehicle privacy protection method based on cloud-based blockchain storage in the Internet of Vehicles (IoV). It constructs a cloud system based on blockchain technology, comprising multiple cloud nodes and a blockchain. Vehicles authenticate their identities through these cloud nodes. The method specifically includes the following steps:

[0059] The vehicle registers with the cloud network. After successful registration, the cloud network generates a permanent identity and a temporary identity for the vehicle.

[0060] When vehicle A needs to interact with other vehicles, vehicle A sends its temporary identity to the cloud and requests a verifiable claim from it;

[0061] A verifiable claim is created in the cloud and fed back to vehicle A. The verifiable claim includes the validity period of the temporary identity Track ID.

[0062] After receiving the verifiable statement, if vehicle A needs to request interaction with vehicle B, it will send the verifiable statement and interaction request to vehicle B.

[0063] Vehicle B can verify the validity of the claim through the public key verification of the cloud system. If the verification is successful, it will accept the interaction request from Vehicle A; otherwise, it will reject it.

[0064] In this embodiment, the invention is described from the aspects of system initialization of the cloud system based on blockchain technology, vehicle identity registration in the system, use of vehicle identity, and periodic updating of temporary identity.

[0065] (I) System initialization of cloud system based on blockchain technology

[0066] When the vehicle networking system is initialized, each car manufacturer's cloud server acts as a cloud node to build a cloud based on a blockchain structure. The cloud nodes generate system public and private key pairs through a decentralized and verifiable secret sharing algorithm.

[0067] When a vehicle leaves the factory, the On-Board Unit (OBU) creates a decentralized identity (DID) based on the vehicle identification code. The DID mainly consists of a DID identifier, a DID public / private key pair, and a DID document. The DID identifier is a string of digital identity, and the DID document stores relevant information about the DID identifier and the DID public / private key pair. One DID identifier corresponds to one DID document.

[0068] In this embodiment, the cloud-based client-server (CS) is built on a blockchain structure, as shown in the following diagram. Figure 1 As shown, each automaker's cloud server joins as a cloud node in the blockchain, and these cloud nodes share the system's public and private key pairs. In addition to the blockchain network, each cloud node also has two main modules: a client and an off-chain distributed database. The client is used to process requests from the on-board unit (OBU), and the distributed database is used to store the vehicle's driving data.

[0069] Decentralized Identity (DID) primarily consists of a DID identifier, a DID public / private key pair, and a DID document. The DID identifier is obtained by converting the VIN code into ciphertext using a random encryption algorithm library. Based on this random encryption algorithm, the VIN code cannot be derived from the DID identifier, nor can the DID identifier be deduced from the VIN code. The DID public / private key pair is mainly used for signature verification. The private key is used for the signing operation and can only be accessed by the owner and cannot be disclosed. The public key is used for signature verification and can be disclosed. The DID document uses a standard data structure, with its field structure as follows: Figure 2 As shown, it is responsible for recording information such as DID identifier, DID public key, and creation time. The DID document stores the vehicle's permanent identity in the vehicle networking system, namely the DID identifier. The relationship between the DID identifier and the DID document is similar to a key-value structure. One DID identifier corresponds to one DID document. The DID document stores the vehicle's public key, which is used to verify the vehicle's identity, and its reliability is guaranteed by the signature of the cloud system.

[0070] (ii) Vehicles are registered in the system.

[0071] The On-Board Unit (OBU) sends its own DID to the cloud-based CS (Customer Service) to apply for registration and join the vehicle-to-everything (V2X) system. The cloud system verifies whether the DID has already been registered. If the verification fails, the registration request is rejected. If the verification is successful, a temporary identity, Track ID, is created for the DID, and both the DID and Track ID are returned to the OBU. At the same time, the DID and Track ID are uploaded to the blockchain network for storage, indicating that the vehicle's identity registration is successful.

[0072] The process of registering a vehicle's identity in the system includes the following steps:

[0073] The S2.1 OBU uses the DID private key to sign the DID identifier and DID document, and then packages the DID identifier, DID document and signature information into a registration request and sends it to the nearest cloud node.

[0074] After receiving the registration request, the nearest cloud node in S2.2 will send the request to other cloud nodes in the cloud system via P2P encrypted communication.

[0075] S2.3 Each cloud node verifies the signature using the public key in the DID document to confirm that the request comes from the correct sender and has not been tampered with. If verification fails, the vehicle registration request is rejected. The sender must properly safeguard their DID private key, ensuring that only they can access it. Once a sender's DID is used to verify a request, the verifier can prevent the same DID from being reused for multiple requests by including the request's timestamp or a random number in the request.

[0076] S2.4 Each cloud node queries the DID identifier in the blockchain network to verify whether the DID has been registered. If the verification fails, the vehicle registration request is rejected.

[0077] In S2.5, each cloud node conducts a consensus vote on the registration request through a consensus protocol. Each cloud node has one vote and only two options: allow registration or refuse registration. The option that receives the most votes within the specified time becomes the voting result. If the voting result is to refuse registration, the cloud node that initially received the request sends a rejection message. If the voting result is to approve registration, subsequent steps are executed.

[0078] Each cloud node in S2.6 uses its system private key to sign the DID document, proving that the DID has been verified.

[0079] S2.7 Each cloud node uses a digest algorithm to generate a temporary identity Track ID corresponding to the DID identifier.

[0080] Each cloud node in S2.8 packages the Track ID, DID identifier, and DID document into a block, with the block structure as follows: Figure 3 As shown, each block is divided into two parts: a block header and a block body. The DID identifier and Track ID are recorded in the ID list in the block header, while the DID document is recorded as a data entry in the block body. The block body includes a Merkle Patricia Tree (MPT). A Merkle tree structure has all the characteristics of a tree. Each node contains two hash values, left and right. The value of a leaf node is the corresponding data information stored in the block, while the hash value of a non-leaf node is calculated based on the hash value of its corresponding child node. Moving upwards, the root node summarizes all the leaf node information in the block, generating a "digital fingerprint" of the entire tree, i.e., the root hash value, used to verify the validity of each block.

[0081] The block header field information is as follows Figure 4 As shown, the data information in the block body is divided into two types: DID document and Verifiable Declaration (VC), both stored in standard JSON format. The block header is an important component of each block in the blockchain. The block header contains complete metadata for the block, used to verify the validity and integrity of the block. The ID list within it stores a list of all data pairs in the block, in the form of (DID identifier, Track ID) tuples when registering an identity or (Track ID, new Track ID) when updating a temporary identity. Each tuple corresponds to a DID document and a Verifiable Declaration (VC) in the block, representing the update record of the temporary identity corresponding to that DID in the system.

[0082] In S2.9, each cloud node conducts a consensus vote on the block through the consensus protocol, broadcasting the hash of its packaged block to the other cloud nodes. Simultaneously, it receives block hashes from the other cloud nodes and compares them with its own packaged block hash. If the hash of the block packaged independently by each cloud node is the same as that of the majority of other cloud nodes, the vote is considered passed, and the block can be added to the blockchain. If the vote fails, the cloud node that initially received the request sends a rejection message.

[0083] S2.10 Each cloud node adds blocks to the cloud blockchain module.

[0084] S2.11 The cloud node that initially received the request signs the DID document and Track ID and sends it back to the OBU.

[0085] The public key of the S2.12 cloud system is disclosed to the vehicle during vehicle registration. After receiving the returned message, the on-board unit (OBU) first verifies the validity of the signature using the public key in the cloud. After verifying the signature, the DID document and Track ID are saved locally as permanent and temporary identities, respectively.

[0086] The specific process for signing and verifying a signature is as follows: Where a signature is required, the data to be signed is calculated using the private key. This calculation generates a unique signature value. This signature value is then appended to the data to be signed, forming a signature message. The signature message is sent to the relevant party requiring verification. The verifier uses the public key to verify the signature message, calculates a value, and compares it with the signature value. If the two values ​​match, the signature is valid, and the signed data has not been tampered with.

[0087] (III) Use of Vehicle Identification

[0088] Decentralized Identity (DID) serves as a permanent identity for vehicles within the connected vehicle system. It is not publicly disclosed and is only used when interacting with the cloud system. During interaction, the On-Board Unit (OBU) first signs the DID identifier and interaction request using its private key and sends them to the cloud system. The cloud system queries the corresponding DID document in the blockchain based on the DID identifier and verifies the signature using the public key in the DID document. If verification fails, the vehicle's interaction request is rejected; if verification succeeds, it proves that the sender is the holder of the DID identifier and has the right to execute subsequent interaction operations.

[0089] Track ID serves as a temporary identity for a vehicle within the connected vehicle system. It has a limited validity period, can be publicly disclosed, and is used during vehicle-to-vehicle interactions. Before interaction, the On-Board Unit (OBU) requests a Verifiable Claim (VC) from the cloud system to prove the vehicle's identity. The VC contains information such as the Track ID's validity period and is signed by the cloud system, declaring the Track ID valid. During interaction, Party A's OBU sends the Verifiable Claim VC containing the Track ID and the interaction request to Party B's OBU. Party B's OBU verifies the cloud system's signature on the VC and the Track ID's validity period within it. If verification fails, the vehicle's interaction request is rejected; if verification succeeds, it proves the Track ID is valid, Party A's identity is valid, and Party A has the right to perform subsequent interaction operations. During vehicle interaction, Party B can request the cloud system to query the Verifiable Claim VC corresponding to the other party's Track ID stored in the blockchain network. By comparing it with the VC sent by Party A, the authenticity of the VC is verified a second time. The process for two-way interactive verification is similar.

[0090] The detailed process by which the OBU queries the cloud system for DID documents using the DID identifier and for verifiable claims (VCs) using the Track ID is as follows: The cloud system retrieves each block in the blockchain based on the DID identifier or Track ID. By quickly searching the ID list in the block header, it quickly locates the block where the DID document or verifiable claim VC is located. Then, it searches within that block and finally obtains the data block of the required verifiable claim VC.

[0091] (iv) Temporary status is renewed periodically.

[0092] The On-Board Unit (OBU) periodically combines its current temporary Track ID with its driving data from that period locally, generates a new temporary identity using a digest algorithm, and sends the new Track ID and driving data to the cloud system (typically, the cloud node closest to the vehicle receives the data and provides feedback on the request). The cloud system verifies the validity of the new Track ID. If verification fails, the temporary identity update request is rejected. If verification succeeds, a verifiable declaration (VC) is created for the new Track ID. The VC contains information such as the validity period of the new Track ID and is signed by the cloud system to declare the new Track ID valid. The cloud system returns the VC to the OBU, uploads the new Track ID and VC to the blockchain network, and stores the driving data in an off-chain distributed database, signifying a successful temporary identity update. Upon receiving the VC from the cloud system, the OBU deletes its current temporary Track ID and the verifiable declaration VC, and uses the new Track ID and the VC returned by the cloud as its new temporary identity.

[0093] The process of periodically renewing temporary status includes the following steps:

[0094] The sensors and other hardware on the S4.1 OBU collect real-time driving data of the vehicle, including location information, throttle opening, brake opening, steering angle, speed, acceleration and braking, and organize the driving data into the standard V2X (vehicle-to-everything) protocol format for temporary storage.

[0095] The S4.2 OBU uses a digest algorithm to generate a digest of the driving data corresponding to the driving data, which is a fixed-length binary string.

[0096] The S4.3 OBU uses a digest algorithm to generate a data digest corresponding to the current Track ID, with the same length as the driving data digest. Then, the driving data digest and the Track ID data digest are concatenated and a new data digest is calculated using the digest algorithm. This new data digest represents the combination of the driving data digest and the Track ID data digest, with the same length as both, and serves as a new temporary identity, `new Track ID`. If any data in this combination changes, the combined digest will differ from the previous value.

[0097] The S4.4 OBU uses the DID private key to sign the DID identifier and the new Track ID, and then packages the DID identifier, new Track ID, driving data and signature information into a temporary identity update request and sends it to the nearest cloud node.

[0098] Once the nearest cloud node in S4.5 receives the request, it will forward the request to other cloud nodes in CS via P2P encrypted communication.

[0099] Each cloud node in S4.6 queries the DID document in the blockchain network based on the DID identifier, verifies the signature based on the public key in the DID document, and verifies whether the request comes from the correct sender and has not been tampered with. If the verification fails, the vehicle's request is rejected.

[0100] S4.7 Each cloud node uses the vehicle's current Track ID stored in the blockchain network to perform the same digest algorithm as the vehicle on the driving data uploaded by the vehicle. The result is compared with the new Track ID to verify whether the vehicle has uploaded forged data. If the verification fails, the vehicle's request is rejected.

[0101] In S4.8, each cloud node votes on update requests using a consensus protocol. Each cloud node has one vote and only two options: agree to the update or reject it. The option that receives the most votes within a specified time becomes the voting result. If the voting result is to reject the update, the cloud node that initially received the request sends a rejection message back. If the voting result is to agree to the update, subsequent steps are executed.

[0102] Each cloud node in S4.9 generates a verifiable declaration (VC) based on the new Track ID, the structure of which is as follows: Figure 5 As shown, the DID document stores the temporary identity of a vehicle in the vehicle-to-everything (V2X) system, namely the Track ID. The relationship between the Track ID and the Verifiable Claim (VC) is similar to a Key-Value structure. One Track ID corresponds to one Verifiable Claim (VC). The Verifiable Claim (VC) stores information such as the vehicle's public key and the validity period of the temporary identity, which is used to verify the validity of the vehicle's temporary identity. The reliability is guaranteed by the signature of the cloud system.

[0103] Each cloud node in S4.10 uses its system private key to sign the VC, proving that the verification of the new Track ID and VC has been completed.

[0104] Each cloud node in S4.11 packages the Track ID, new Track ID, and VC into a block. The Track ID and new Track ID are recorded in the ID list in the block header, while the VC is recorded as a piece of data in the block body.

[0105] In S4.12, each cloud node conducts a consensus vote on the block through the consensus protocol, broadcasting the hash of the packaged block to the other cloud nodes, and simultaneously receiving the block hashes sent by the other cloud nodes, comparing them with its own packaged block hash. If the block hash independently packaged by each cloud node is the same as that of the majority (generally more than half) of the other cloud nodes, the vote is considered passed, and the block can be added to the blockchain. If the vote fails, the cloud node that initially received the request sends a rejection message.

[0106] S4.13 Each cloud node adds blocks to the cloud blockchain module.

[0107] In S4.14, each cloud node stores driving data summaries and driving data in the form of hash tables in an off-chain distributed database, while only driving data summaries are stored on the chain, making it easy to retrieve and verify whether the driving data has been tampered with.

[0108] S4.15 The cloud node that initially received the message signs the VC and sends it back to the OBU.

[0109] The public key in the S4.16 cloud is disclosed to the vehicle during vehicle registration. After receiving the returned message, the On-Board Unit (OBU) first verifies the validity of the signature using the public key in the cloud. After verifying the signature, the OBU saves the VC locally and uses it together with the new TrackID as a new temporary identity.

[0110] This invention utilizes a blockchain-based chain structure. By using a DID identifier, all Track IDs generated from that DID can be retrieved. Combined with the driving data digest in the Verifiable Declaration (VC) corresponding to the Track ID, the entire process of updating vehicle identity information can be traced, providing significant auditing value. Due to the blockchain's backward-only retrieval capability, the corresponding DID identifier and DID document cannot be retrieved using the Track ID, effectively protecting vehicle privacy and security.

[0111] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for protecting vehicle privacy in the Internet of Vehicles (IoV) based on cloud-stored blockchain, characterized in that, Constructing a cloud system based on blockchain technology, which includes multiple cloud nodes and a blockchain, allows vehicles to authenticate their identities through the cloud nodes. This process includes the following steps: The vehicle registers with the cloud network. After successful registration, the cloud network generates a permanent identity and a temporary identity for the vehicle. When vehicle A needs to interact with other vehicles, vehicle A sends its temporary identity to the cloud and requests a verifiable claim from it; A verifiable claim is created in the cloud and fed back to vehicle A. The verifiable claim includes the validity period of the temporary identity Track ID. After receiving the verifiable statement, if vehicle A needs to request interaction with vehicle B, it will send the verifiable statement and interaction request to vehicle B. Vehicle B can verify the validity of the claim through the public key verification of the cloud system. If the verification is successful, it will accept the interaction request from Vehicle A; otherwise, it will reject it. Each vehicle's temporary Track ID has an expiration date and needs to be updated periodically. The update process includes: A new temporary identity, new Track ID, is generated by combining the vehicle's driving data during the validity period of the current temporary identity with a digest generation algorithm. The vehicle uses the private key corresponding to the DID document to sign the DID identifier and the new Track ID, and packages the DID identifier, new Track ID, driving data and signature information into a temporary identity update request and sends it to the nearest cloud node; After receiving the temporary identity update request, the cloud node will send the request to other cloud nodes via P2P encrypted communication; The cloud node queries the DID document in the blockchain network based on the DID identifier, verifies the signature based on the public key in the DID document, and verifies whether the request comes from the correct sender and has not been tampered with. If the verification fails, the vehicle's request is rejected. The cloud node uses the vehicle's current Track ID stored in the blockchain network and performs the same digest algorithm as the vehicle on the driving data uploaded by the vehicle. The result is compared with the new Track ID to verify whether the vehicle has uploaded forged data. If the verification fails, the vehicle's request is rejected. Cloud nodes use a consensus protocol to vote on update requests. Each cloud node has one vote and only two types of votes: agree to update or reject update. The option that receives the most votes within a specified time becomes the voting result. If the voting result is to reject update, the node that first received the request will send a message rejecting update. If the voting result allows the update, the cloud node generates a verifiable claim based on the new Track ID. The cloud node then signs the verifiable claim using the system private key to prove that the new Track ID and the corresponding verifiable claim have been verified. The cloud node packages the Track ID, new Track ID, and generated verifiable claim into a block. The Track ID and new Track ID are recorded in the ID list in the block header, and the verifiable claim is recorded as a piece of data in the block body. Each node votes on the block through the consensus protocol, broadcasts the hash of the packaged block to the other nodes, and receives the block hashes sent by the other nodes and compares them with the hash of its own packaged block. If the hash of the block packaged independently by each node is the same as that of the majority of other nodes, the vote is considered to have passed, and the block can be added to the blockchain. The cloud node that initially received the temporary identity update request will send the verifiable statement back to the vehicle after signing it with the system private key. If the vote fails, the cloud node that initially received the temporary identity update request sends a rejection message.

2. The vehicle privacy protection method based on cloud storage blockchain in the Internet of Vehicles according to claim 1, characterized in that, The vehicle's own identity information is a decentralized identity created by the on-board unit based on the vehicle identification code. The decentralized identity includes a DID identifier, a DID public-private key pair, and a DID document. The DID identifier is a string of digital identity, and the DID document stores the information of the DID identifier and the DID public-private key pair. One DID identifier corresponds to one DID document.

3. A method for protecting vehicle privacy in a vehicle-to-everything (V2X) network based on cloud-based blockchain, as described in claim 2, characterized in that... The DID identifier is obtained by converting the vehicle's VIN code into ciphertext using a random encryption algorithm. This means that the VIN code cannot be deduced from the DID identifier, nor can the DID identifier be deduced from the VIN code.

4. A method for protecting vehicle privacy in a vehicle-to-everything (V2X) network based on cloud-based blockchain, as described in claim 2, characterized in that... The data structure of a DID document is represented as {id, created, updated, publicKey, proof}, where id stores the DID identifier, created stores the time the DID document was created, updated stores the time the DID document was maintained, publicKey stores the vehicle public key information associated with the current DID document, and proof stores the proof of the current DID document.

5. A method for protecting vehicle privacy in a vehicle-to-everything (V2X) network based on cloud-based blockchain, as described in claim 2, characterized in that... When a vehicle applies for a verifiable declaration from the cloud, if the vehicle is not currently registered in the vehicle network, the registration process includes the following steps: Vehicles that need to be registered send their DID identifier and DID document, signed with their own private key, to the nearest cloud node. Upon receiving the registration request, the cloud node will forward the request to other cloud nodes in the network via P2P encrypted communication. All cloud nodes that receive the registration request verify the signature using the public key in the DID document, verifying that the request comes from the correct sender and has not been tampered with. If the verification fails, the vehicle registration request is rejected. If the verification is successful, each cloud node queries the DID identifier in the blockchain network to verify whether the DID has been registered. If it has been registered, the vehicle registration request is rejected. If no registration is made, each node in the cloud will vote on the registration request through a consensus protocol. Each node has only one vote and can only vote for either allowing or rejecting registration. The node with the most votes of each voting type within the specified time will be the voting result. If the voting result is to reject registration, the cloud node that initially received the registration request message will send back a message rejecting registration. If the voting result allows registration, each cloud node uses the private key of the cloud system to sign the DID document to prove that the DID has been verified; Each cloud node uses a digest algorithm to generate a temporary identity Track ID corresponding to the DID identifier. Each cloud node then packages the Track ID, DID identifier, and DID document into a block. Cloud nodes use a consensus protocol to vote on blocks, broadcast the hash of the packaged block to other cloud nodes, and receive the block hashes sent by other cloud nodes, comparing them with the hash of their own packaged blocks. If the hash of the block packaged independently by each cloud node is the same as that of the majority of other cloud nodes, the vote is considered to have passed, and the block can be added to the blockchain. The cloud node that initially received the request will sign the DID document and Track ID using the private key of the cloud system and send them back to the vehicle. Otherwise, the node that initially received the request sends a rejection message. After successful vehicle registration, the cloud system's public key is made public to the vehicle. Upon receiving the rejection message, the vehicle verifies the validity of the signature using the cloud's public key. After verifying the signature, the DID document and Track ID are stored locally, with the DID document serving as the vehicle's permanent identity and the Track ID serving as the vehicle's temporary identity.

6. A method for protecting vehicle privacy in a vehicle-to-everything (V2X) network based on cloud-based blockchain, as described in claim 5, is characterized in that... The Track ID, DID identifier, and DID document are packaged into a block. In its block structure, the DID identifier and Track ID are recorded in the ID list of the block header, and the DID document is recorded as a data record in the block body.

7. A method for protecting vehicle privacy in a vehicle-to-everything (V2X) network based on cloud-based blockchain, as described in claim 1, characterized in that... The data structure for a verifiable claim is represented as {id, issuanceDate, expirationDate, publicKey, dataHsah, proof}, where id stores the vehicle's current temporary identity, Track ID; issuanceDate stores the issuance time of the current verifiable claim; expirationDate stores the expiration time of the current verifiable claim; publicKey stores the vehicle's public key information associated with the current verifiable claim; dataHsah stores the driving data digest corresponding to the Track ID associated with the current verifiable claim; and proof stores the proof of the current verifiable claim.

8. A method for protecting vehicle privacy in a vehicle-to-everything (V2X) network based on cloud-based blockchain, as described in claim 1, characterized in that... The process of generating a new temporary identity, new Track ID, by combining the vehicle's driving data during the current temporary identity's validity period with a digest generation algorithm includes: The vehicle uses the Track ID generated by the digest algorithm in the previous cycle as the first data digest; A driving data digest corresponding to the driving data is generated using a digest algorithm, which serves as the second data digest, and the first and second data digests have the same length. The first and second data summaries are joined together by aggregation, and the concatenated data is used to generate a third data summary using a digest algorithm. Use the third data digest as the new Track ID.

Images