A blockchain-based secure transfer method for data ownership in vehicle networking

Abstract

This invention belongs to the field of vehicle network data security technology, specifically involving a blockchain-based method for secure transfer of vehicle network data ownership. The method includes: a trusted authorized institution building a blockchain network based on Hyperledger Fabric and deploying smart contracts integrating access control, combined with CP-ABE encryption mechanism to achieve data security management; after the vehicle owner registers as the data owner, encrypted vehicle network data is uploaded to a cloud server, where the cloud server generates asset metadata and completes on-chain ownership registration; after the data user verifies their identity and permissions through the smart contract, they retrieve the corresponding data from the cloud server using an access token; during data ownership transfer, the current owner submits a signed transfer request, which is verified as legitimate by the smart contract, updating the on-chain asset metadata, while the cloud server only synchronously updates the owner identifier and version record. This solution achieves the linkage between access control and integrity verification, significantly reducing the computational and communication costs of ownership transfer. The immutability of blockchain makes data access and ownership transfer traceable throughout the entire process, effectively ensuring the confidentiality and integrity of vehicle network data, and meeting the needs of secure and efficient circulation of data assets with multiple stakeholders.

Description

Technical Field

[0001] This invention belongs to the field of vehicle network data ownership transfer and cloud storage security technology, specifically involving a blockchain-based method for secure transfer of vehicle network data ownership. Background Technology

[0002] With the continuous development of intelligent transportation and Internet of Vehicles (IoV) technologies, vehicles continuously collect a large amount of high-value data during operation through onboard sensors, ECU units, onboard terminals, and V2X communication modules. This data includes information such as speed, location, energy consumption, driving behavior, vehicle health, and road environment. This data not only supports core business functions such as intelligent navigation, accident analysis, traffic scheduling, and vehicle maintenance, but is also gradually evolving into important "digital assets" in emerging applications such as insurance pricing, accident liability determination, vehicle traceability management, and data trading platforms. Against this backdrop, how to establish, authorize, audit, and transfer ownership of IoV data has become a key issue for the transportation system in the digital age.

[0003] Currently, in-vehicle terminals typically upload collected data to cloud servers for centralized storage and analysis. However, cloud servers are often considered "semi-trusted entities," posing potential risks of data leakage, tampering, or unauthorized use. More importantly, the Internet of Vehicles (IoV) involves multiple stakeholders, including vehicle owners, manufacturers, insurance companies, regulatory bodies, and maintenance service providers. Different stakeholders have different usage rights, access intentions, and legal rights to the same data asset, which places higher demands on data ownership management, authorized access, and cross-stakeholder data flow.

[0004] To ensure data access security, existing research has proposed Attribute-Based Encryption (ABE) for fine-grained access control; and Provable Data Holding (PDP) mechanisms to verify the correctness and availability of cloud data, allowing data owners to verify whether the data is actually stored in the cloud without downloading it. However, these solutions still have significant shortcomings in real-world connected vehicle scenarios: on the one hand, ABE and PDP are often designed separately, lacking linkage between access control and data integrity verification, failing to ensure that "only data that passes integrity verification can be authorized for access"; on the other hand, for dynamic scenarios in connected vehicles such as user revocation, vehicle ownership changes, and cross-agency data flow, traditional solutions often require re-encrypting all data or regenerating verification tags, resulting in huge computational and communication costs, making it difficult to meet the real-time and economic requirements of large-scale connected vehicle systems.

[0005] Meanwhile, existing systems lack a trustworthy, transparent, and auditable data management mechanism. Third-party audit results may be falsified or rejected, and existing solutions struggle to provide continuous and traceable oversight of access behavior, verification processes, and ownership transfers. While blockchain technology, with its immutable, decentralized, and traceable characteristics, provides a new technological foundation for data ownership confirmation, access record registration, and audit credibility, existing blockchain solutions still cannot effectively address the following core issues: on-chain data ownership confirmation; efficient and secure data ownership transfer without re-encryption; unified access control, integrity verification, and audit records; and transparency, trustworthiness, and verifiability of the entire multi-entity data management process.

[0006] Therefore, there is an urgent need for a unified framework that can integrate blockchain, attribute-based encryption, and provable data holding technologies to ensure the confidentiality, integrity, and traceability of vehicle-to-everything (V2X) data, while enabling asset-level ownership management, low-cost ownership transfer, and a trusted mechanism for data access and auditing for multiple stakeholders. This would meet the security and regulatory needs for the circulation of large-scale, cross-institutional, and high-value data assets in the V2X environment. Summary of the Invention

[0007] To address the problems existing in the background technology, the present invention provides a blockchain-based method for secure transfer of vehicle network data ownership, comprising:

[0008] S1: A trusted authorized institution creates a blockchain network based on Hyperledger Fabric and adopts the PoA consensus protocol. Within this network, smart contracts with integrated access control functions are deployed, and the CP-ABE encryption mechanism is used to handle access control and ownership transfer of vehicle network data.

[0009] S2: The car owner registers as a data owner (DO) on the blockchain network. The data owner (DO) encrypts the original data of the vehicle network and uploads it to the cloud server. The cloud server integrates the encrypted data to generate asset metadata, and then completes the confirmation and registration of asset metadata through smart contracts.

[0010] S3: When a data user DU needs to access vehicle network data, it submits an access request to the smart contract. After the smart contract completes the verification of the data user DU's identity and access permissions, it returns a confirmation result and an access token. The cloud server returns the corresponding asset metadata to the data user DU based on the confirmation result and access token.

[0011] S4: When the ownership of vehicle network data needs to be transferred from the current data owner to the new data owner, the current data owner submits an ownership transfer request to the smart contract. After the smart contract verifies the legality of the transfer request, it updates the asset metadata and writes it to the blockchain. The cloud server only updates the owner's identifier and version record synchronously, realizing a secure and lightweight transfer of data ownership.

[0012] The present invention has at least the following beneficial effects

[0013] This invention constructs a vehicle-to-everything (V2X) data management system based on the Hyperledger Fabric blockchain and integrating the CP-ABE encryption mechanism. Relying on smart contracts, it achieves end-to-end on-chain control of asset metadata registration, access permission verification, and ownership transfer. On one hand, it deeply links access control with data integrity verification, and combines a verifiable access proof mechanism from a third-party auditing institution to effectively avoid the risks of cloud data leakage, tampering, and unauthorized access, ensuring the confidentiality and integrity of V2X data. On the other hand, during data ownership transfer, only the on-chain asset metadata and the owner identifier and version record in the cloud need to be updated, eliminating the need for repeated encryption and verification tag generation of massive amounts of V2X data. This significantly reduces computing and communication costs and adapts to the real-time requirements of large-scale V2X systems. Simultaneously, the immutability and traceability of the blockchain ensure that data access behavior and ownership transfer information are transparently recorded on-chain, creating a trustworthy end-to-end regulatory mechanism. This achieves asset-level ownership management and low-cost secure transfer of V2X data assets, meeting the security and regulatory needs for the orderly circulation of high-value V2X data assets with multi-party participation. Attached Figure Description

[0014] Figure 1 This is a diagram illustrating the architecture of the present invention. Detailed Implementation

[0015] 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.

[0016] Please see Figure 1 This invention provides a blockchain-based method for secure transfer of vehicle network data ownership, comprising:

[0017] Trusted Authorization Authority (AA) creates a blockchain network based on Hyperledger Fabric, using the PoA consensus protocol. The network node deployment architecture is as follows: AA serves as the consensus node and endorsement node, cloud servers and third-party auditors (TPA) serve as endorsement nodes, and data owners (DO) and data users (DU) serve as ordinary nodes. Smart contracts with integrated access control functions are deployed in this network, and the CP-ABE encryption mechanism is used to handle access control and ownership transfer of vehicle network data.

[0018] S1: A trusted authorized institution creates a blockchain network based on Hyperledger Fabric and adopts the PoA consensus protocol. In this network, smart contracts with integrated access control functions are deployed, and the CP-ABE encryption mechanism is used to handle access control and ownership transfer of vehicle network data.

[0019] Preferably, the CP-ABE encryption mechanism includes three steps: public parameter generation, key generation, and data encryption, specifically:

[0020] Step 1: Common Parameter Generation: Trusted Authorization Authority Inputs Security Parameters Generate bilinear group parameters, wherein the bilinear group parameters contain prime numbers of order. group, generator and bilinear pair and randomly select those belonging to The system public key PK and master key MK are calculated from the parameters, thus completing the deployment of global system parameters. Representing prime numbers The non-zero integer field;

[0021] Step 2: Key Generation: Trusted Authorization Authority AA generates a private key SK for the user based on the user's attribute set S using the master key MK. The private key SK contains relevant keys corresponding to the user's attributes, thus binding the private key to the user's attributes.

[0022] Step 3: Data Encryption: The data owner DO selects the original plaintext data of the vehicle network, combines it with the LSSS-based access policy, and constructs the ciphertext CT through the system public key PK. The ciphertext CT contains the global ciphertext and the component associated with the access policy, so as to realize fine-grained access control of the vehicle network data.

[0023] In this embodiment, to enable readers to more clearly understand the solution of this application, the following specific description is provided;

[0024] Phase 1: Trusted Authorization Authority (AA) executes system initialization, generating global keys and attribute fields.

[0025] Step 1: Generate the basic parameters of the CP-ABE bilinear group

[0026] AA takes the safety parameter λ as input and generates the core parameters of the bilinear group, satisfying the bilinear pairing operation. ; and All are of order. cyclic group It is a large prime number; for Generators;

[0027] Step 2: Generate the CP-ABE system public key PK and master key MK

[0028] AA from Randomly select parameters , express The non-zero integer field; calculate , ; Obtain the system master key System public key ;

[0029] Step 3: Define the global access control attribute domain

[0030] AA combines vehicle-to-everything (V2X) business scenarios (regulation, insurance, automakers, maintenance, etc.) to extract independent attribute dimensions and construct a global attribute set. As a basic element of access strategy:

[0031]

[0032] in, It indicates a single attribute, such as regulatory agencies, insurance companies, and car owners;

[0033] Phase Two: A trusted authorized agency performs user registration and generates user attribute private keys and identity identifiers.

[0034] Step 1: User Identity Verification and Unique Identifier Assignment

[0035] DO / DU submits a registration application to AA. After AA approves the application, it assigns a unique identifier to the data owner DO: the identifier assigned to the data owner DO is represented as follows. The identity identifier assigned to data user DU is represented as follows: AA synchronizes the DO / DU's identity identifier, identity information, and registration time to the blockchain smart contract, completing on-chain identity verification.

[0036] Step 2: Assign attribute set S to the user

[0037] AA uses the global attribute set to determine the user's organization type, business permissions, and role. It is assigned a unique set of attributes:

[0038] The attribute set of DO is represented as follows: (e.g., the owner of the vehicle, license plate number XXX); DU's attribute set (Insurance institutions, XX brand car manufacturers):

[0039] Step 3: Generate user attribute private key

[0040] AA uses the system master key and user attribute set Call the key generation algorithm Generate a private key for the user that is bound to the attribute. ;

[0041]

[0042] ,

[0043] The private key of DO is represented as (Also serving as the private key for DO's signing), the private key of DU is represented as follows: (Also serving as the private key for DU's signature); AA will use the user attribute set S and the attribute private key. Binding to the identity identifier, the digest is uploaded to the blockchain (the digest is the user's identity identifier). User attribute set S and attribute private key The hash digest provides a basis for subsequent permission verification.

[0044] Phase 3: Trusted Authorization Authority (AA) constructs access control policies, generates policy identifiers, and stores evidence on the blockchain.

[0045] Step 1: Build the access policy tree

[0046] AA converts access authorization requirements into Boolean / threshold logic expressions, using a global attribute set. Based on this, an access policy tree is constructed using AND / OR / Threshold operations;

[0047]

[0048] in, For logical rules (such as) ), This is a policy generation algorithm; policy tree structure: root node = overall policy, leaf nodes = specific attributes. Non-leaf nodes = logical operations (AND / OR / Threshold).

[0049] Step 2: Generate a unique policy identifier With tamper-proof hash value

[0050] For each access policy tree Assign a unique policy identifier ;

[0051] AA calculation strategy tree tamper-proof hash value Integrating the AA logo and generate timestamps To ensure the strategy cannot be tampered with:

[0052]

[0053] Step 3: Strategy on-chain storage and synchronization across the entire network

[0054] AA will use strategy triples Write it into the blockchain, where, The policy description summary includes the core information of the policy, including but not limited to: the connected vehicle scenario to which the policy applies (such as access to regulatory data or insurance loss assessment data), the scope of permissions of the policy (such as the types of data that can be accessed and the applicable user groups), and a summary of the core authorization rules of the policy (such as "only regulatory agencies can access the basic vehicle data across the entire domain").

[0055] At the same time, the strategy content or strategy identifier Synchronize with DO, cloud server (CSP), and third-party auditor (TPA) to ensure that the authorization basis of all participants is consistent;

[0056] For vehicle-to-everything (V2X) data with multiple data blocks, AA integrates the associated policy identifiers into a policy set reference. ,in, Describes the number of data blocks.

[0057] In this embodiment, the trusted authorization institution builds a blockchain network based on Hyperledger Fabric and adopts the PoA consensus protocol. At the same time, it deploys smart contracts with integrated access control functions and combines them with the CP-ABE encryption mechanism. This not only relies on the decentralized and tamper-proof characteristics of blockchain to build a trusted underlying architecture for vehicle network data management, but also realizes on-chain automated management and control of access control, permission verification, and ownership transfer through smart contracts. Furthermore, it provides fine-grained access control technology support for vehicle network data with the help of the CP-ABE encryption mechanism. From the underlying architecture to the functional implementation and encryption security, this lays a secure, reliable, and efficient technical foundation for the entire process of vehicle network data confirmation, access, and ownership transfer.

[0058] S2: The car owner registers as a data owner (DO) on the blockchain network. The data owner (DO) encrypts the original data of the vehicle network and uploads it to the cloud server. The cloud server integrates the encrypted data to generate asset metadata, and then completes the confirmation and registration of asset metadata through smart contracts.

[0059] Preferably, the process of completing the asset metadata ownership registration via smart contracts includes:

[0060] S21: The vehicle owner completes registration on the blockchain network, becomes the data owner (DO), and obtains a unique identity identifier. Vehicle driving data is divided into multiple data blocks according to preset rules. Each data block is encrypted using the CP-ABE encryption mechanism. Generate ciphertext and integrity tags ;

[0061] S22: Data owner DO will put all encrypted data... and corresponding integrity tags After being uploaded to the cloud server, the cloud server integrates and generates asset metadata (AM), which includes:

[0062]

[0063] in, Identifiers representing asset metadata; This indicates the version number and its initial value is 1; Represents a random number. Represents a set of integrity labels The index is used to quickly locate each data block. Tag information; The asset is in a certain state and is initially set to... Activated state; A policy set reference that points to all access policies associated with the asset's metadata; Indicates the timestamp of asset metadata generation;

[0064] S23: The cloud server uploads the generated asset metadata AM to the blockchain smart contract to complete the registration of ownership of the vehicle network data asset.

[0065] In this embodiment, the third stage immediately following step S1 will be described further;

[0066] Phase Four: The data owner performs data encryption to generate ciphertext, integrity tags, and asset metadata;

[0067] Step 1: Divide the raw data into blocks

[0068] DO will collect the raw data set of the vehicle network (VRS) Each record At least vehicle identification timestamp GPS location information, driving speed, fuel level and / or vehicle status information) are divided into data blocks according to preset rules. Generate a random symmetric key for each data block. ,right Perform symmetric encryption:

[0069]

[0070] in, It is a symmetric encryption algorithm.

[0071] Step 2: Policy Encryption Based on CP-ABE

[0072] DO for each data block Binding access policy (Selected from AA synchronization strategies), using the system public key PK to pair the symmetric key. Perform CP-ABE encryption to generate the key ciphertext. :

[0073]

[0074] Combine the encrypted data to generate the final ciphertext block. :

[0075]

[0076]

[0077] in, This indicates the CP-ABE encryption algorithm;

[0078] Step 3: Generate data block integrity tags With PDP verification label ;

[0079] (1) Generate integrity tags

[0080] DO generates an access policy identifier for each ciphertext block. Data block identifier Calculate the ciphertext hash and through its own private key Signature, generate integrity tag ;

[0081]

[0082]

[0083] in, and Represents a random number; Indicates the vehicle's unique identifier; Indicates the data block index number; Indicates the timestamp of data block collection;

[0084]

[0085] in, For DO via private key Execution of ECDSA signature;

[0086] (2) Generate block-level integrity tags With PDP verification label

[0087] Constructing ciphertext blocks metadata vector ; ,in A unique identifier for the ciphertext block. For vehicle identification, This is the encrypted version number, initially set to 1, and incremented by 1 with each subsequent version number update; ;

[0088] Generate block-level integrity tags :

[0089]

[0090] Generate PDP verification label :

[0091] DO utilizes PDP mechanism parameters to Mapping to group elements ,Will Mapped to exponent :

[0092] ,

[0093] ,

[0094]

[0095]

[0096] in, The random number is generated by AA for each data user during the system initialization phase and sent to the corresponding data user through a secure channel; the random number mentioned in this application from Selected from;

[0097] Step 4: Construct asset metadata AM and put it on the blockchain for ownership confirmation

[0098] DO will collect all ciphertext blocks CT and tags. , and Uploaded to the cloud server, the cloud server integrates and generates asset metadata (AM), first generating a unique asset identifier (AID):

[0099]

[0100] Reconstruct the structured asset metadata AM:

[0101]

[0102] in: This indicates the version number and its initial value is 1; Represents a random number. Represents a set of integrity labels The index is used to quickly locate each data block. Tag information; The asset is in a certain state and is initially set to... Activated state; A policy set reference that points to all access policies associated with the asset's metadata; Indicates the timestamp of asset metadata generation;

[0103] The cloud server uploads AM to the blockchain smart contract to complete the on-chain registration of vehicle network data assets;

[0104] When verifying data integrity, the third-party auditing firm (TPA) performs a three-level joint verification:

[0105] First, verify the block-level integrity label. ,contrast With on-chain storage If they match, proceed to the next step; secondly, verify the integrity label. Verify the signature using the DO public key. and compare and If the hash values ​​match, proceed to the next step; finally, verify the PDP verification label. The PDP mechanism is used to perform ownership verification. If the verification passes, the data is considered complete. If any level of verification fails, the data is considered corrupted or tampered with. The data access request is immediately rejected, and the abnormal information is recorded on the blockchain.

[0106] In this embodiment, by having vehicle owners register on the blockchain network to become legitimate data owners, the original vehicle network data is encrypted and uploaded to the cloud server. The cloud server then integrates and generates standardized asset metadata and completes on-chain ownership registration. This not only strengthens the storage security of vehicle network data through CP-ABE encryption, but also realizes asset-level ownership confirmation of vehicle network data through blockchain smart contracts, giving the data a legitimate ownership identifier. At the same time, the encrypted data and asset metadata are managed in layers, laying a standardized and traceable data asset foundation for subsequent authorized access and ownership transfer of data, and avoiding the risks of leakage and tampering caused by direct storage of original data in the cloud.

[0107] S3: When a data user DU needs to access vehicle network data, it submits an access request to the smart contract. After the smart contract completes the verification of the data user DU's identity and access permissions, it returns a confirmation result and an access token. The cloud server returns the corresponding asset metadata to the data user DU based on the confirmation result and access token.

[0108] Preferably, step S3 specifically includes:

[0109] S31: Data user DU obtains the asset metadata AM of the target vehicle network data from the blockchain network and parses it to obtain the unique asset identifier. and access strategy set reference Generate access request , Represents a timestamp. Represents a random number, and is generated using its own private key. The hash value of the access request information is used to sign the request using the ECDSA algorithm. and the access request and digital signatures Send to the blockchain smart contract; Indicates referencing from the access policy set The selected access policy identifier;

[0110] S32: The smart contract receives an access request from data user DU. With digital signatures Then, the verification algorithm is executed to verify the identity, signature, and access permissions of the data user DU;

[0111] In this embodiment, after the smart contract receives the access request and digital signature of data user DU, it executes a four-dimensional verification algorithm to verify data user DU. If all verifications pass, the process proceeds to the next step; if any verification fails, access is directly denied.

[0112] Authentication: Verification It is a legitimate registered user of AA, and its identity information is validly stored on the blockchain;

[0113] Signature verification: using The corresponding public key verifies the digital signature. The validity of the request is verified to prevent it from being tampered with.

[0114] Replay protection verification: Check and Ensure the request is valid within 10 minutes, and Not reused;

[0115] Access control verification: Verify the set of attributes of the DU. Foot access strategy It was determined that the user possessed the corresponding access permissions.

[0116] S33: After successful verification, the smart contract returns the verification result and access token to the data user DU. The data user DU uses the access token to submit a request to the cloud server to obtain the encrypted data. After verifying the validity of the token, the cloud server returns the corresponding encrypted data to the data user DU. If the verification fails, the smart contract directly rejects the data user DU's access request.

[0117] In this embodiment, the access token is a single-use access token with a validity period of 1 hour. Data user DU submits a request to the cloud server to obtain encrypted data using the access token. The cloud server verifies the validity of the token (including the token signature, validity period, and binding relationship with AID) and then returns the corresponding encrypted data to the user. If the verification fails, the smart contract directly rejects the access request of data user DU.

[0118] Preferably, the CP-ABE encryption mechanism further includes a data decryption step: if the decryptor's own attribute set satisfies the access policy associated with the ciphertext, the decryptor uses its own private key SK to perform bilinear pairing calculations, combined with the LSSS secret reconstruction method to eliminate redundant components in the ciphertext, and finally recovers the original plaintext data of the vehicle network, thus completing the attribute-driven conditional decryption.

[0119] Preferably, after the data user DU obtains the encrypted data, the system combines the integrity tag of the encrypted data with the metadata on the blockchain to generate a verifiable access certificate. The verifiable access certificate is then verified by a third-party auditing institution TPA. Only after the verification is successful can the data user DU perform the decryption operation.

[0120] In this embodiment, the description continues immediately following the fourth stage of step S2;

[0121] Phase 5: Data users execute access requests to generate access trapdoors and signature requests, completing permission verification.

[0122] Step 1: DU generates access trapdoor DU obtains the AM of the target asset from the blockchain and parses it. Select a matching strategy identifier based on its own attribute set S. (Corresponding strategy) The trapdoor generation algorithm TrapGen is invoked to generate access trapdoors. ;

[0123]

[0124] Step 2: DU generates access request and digital signature :

[0125]

[0126] DU uses its own private key The request information was hashed and signed using the ECDSA algorithm to obtain:

[0127]

[0128] DU will visit the triplet Send to smart contract / cloud server;

[0129] Step 3: Smart contract / cloud server execution permission verification

[0130] Verification using DU's public key ,examine and To prevent request replay; invoke the access verification algorithm. Verify the trapdoor Does the strategy meet the requirements?

[0131]

[0132] If returned Access is directly denied, and the process is terminated; if a response is received... CSP filters out a subset of ciphertext that meets the policy. , Synchronization tag and Submit it to TPA for integrity verification.

[0133] TPA performs integrity verification and issues access tokens.

[0134] TPA, combined with AM on the blockchain, for ciphertext subsets Perform PDP holding verification. Once verification is successful, an access token τ is generated, and the token issuance record is recorded on the blockchain.

[0135]

[0136] in, The digital signature generated by TPA using the ECDSA algorithm, the token The unique credential for obtaining ciphertext for DU.

[0137] Step 5: Decrypt the ciphertext and recover the original data using DU.

[0138] DU with access token Obtain a subset of ciphertext from the CSP Using its own attribute private key Execute CP-ABE decryption algorithm First, solve for the symmetric key. Then restore the original data. ;

[0139]

[0140]

[0141] in, The algorithm is a symmetric decryption algorithm. After decryption, the system will record the access behavior ( , Access time The data is uploaded to the blockchain, forming an unalterable audit record.

[0142] In this embodiment, data users submit signed access requests to a smart contract. The smart contract performs multi-dimensional verification of identity, signature, and access permissions. Combined with integrity verification by a third-party auditing institution, a unique access token is issued. The cloud server provides the corresponding encrypted data based on the valid token. This achieves fine-grained, high-security authorized access to vehicle network data through on-chain automated verification by the smart contract, eliminating the risk of unauthorized access. It also deeply links access permission verification with data integrity verification, ensuring that users can only access complete and tamper-proof data. At the same time, the entire access process is recorded on the blockchain to form an immutable audit record, making the data access process traceable and monitorable. Furthermore, the dedicated management of access tokens further enhances the security and standardization of data access.

[0143] S4: When the ownership of vehicle network data needs to be transferred from the current data owner to the new data owner, the current data owner submits an ownership transfer request to the smart contract. After the smart contract verifies the legality of the transfer request, it updates the asset metadata and writes it to the blockchain, thus realizing the secure transfer of data ownership.

[0144] Preferably, step S4 specifically includes the following steps:

[0145] S41: Current data owner Construct an ownership transfer request At the same time, using its own private key Sign the hash value of the transfer request information to obtain:

[0146]

[0147] in, Represents a random number. Indicates the identity of the current data owner; Indicates the transfer type identifier; Represents a random number; Represents a timestamp; Indicate the identity of the new data owner; and submit the transfer request. With digital signatures Send to the smart contract;

[0148] S42: After receiving the ownership transfer request and digital signature, the smart contract verifies the identity of the current data owner, the signature, and the legality of the transfer request; upon successful verification, the ownership transfer is executed, and the smart contract updates the asset-level metadata. Identify the data owner Replace with the identity of the new data owner and update the version number. At the same time, the updated asset-level metadata will be... Write it into the blockchain network.

[0149] Preferably, when transferring data ownership in step S4, the cloud server only synchronously updates the owner identifier and version record in the metadata of the corresponding data block stored locally, while the encrypted and integrity tags of the vehicle network data remain unchanged, thus avoiding repeated encryption and transmission of massive amounts of data.

[0150] Preferably, the smart contract writes information about each change in ownership of vehicle network data into the blockchain network, forming a transparent, tamper-proof, and traceable ownership chain, thereby enabling full supervision of the data ownership transfer process.

[0151] In this embodiment, the description continues immediately following the fifth stage of step S3;

[0152] Phase 6: The data owner executes the ownership transfer, generates a transfer request and signature, and completes the on-chain metadata update;

[0153] Step 1: Generate ownership transfer request With signature ;

[0154] Determine the new data owner Generate a transfer request (including assets, identities of both parties, and transfer type):

[0155]

[0156] in, For transfer type identification (such as vehicle transaction, authorized sharing, etc.);

[0157] Using your own private key The request information is hashed and signed to obtain:

[0158] Transfer the binary Send to the blockchain smart contract, and simultaneously to Send transfer notification, Upon receiving the transfer notification, submit a voluntary confirmation receipt to the smart contract (including...). , After confirming the signature, the smart contract verifies the validity of the receipt and proceeds to the verification stage.

[0159] Step 2: Smart contract execution transfer request verification

[0160] The smart contract performs verification on the request; if all verifications pass, the transfer is allowed; otherwise, it is rejected.

[0161] Authentication: Verification The rightful owner of asset AID (matching the on-chain AM) ;

[0162] Signature verification: using Public key verification Validity;

[0163] Verify the validity period of the request. Whether it is used;

[0164] Validity verification: Verification For AA's legally registered users, the transfer type is... Complies with system rules;

[0165] Step 3: The smart contract updates the asset metadata AM and uploads it to the blockchain.

[0166] After successful verification, the smart contract performs an incremental update on the asset metadata AM, generating the updated asset metadata Updated AM. Only the owner identifier, version number, and asset status are modified, while the remaining fields remain unchanged.

[0167]

[0168] Version numbers are monotonically incremented, enabling migration tracking; Asset status update (e.g., from Active to Active) , ; This represents a predefined state transition function that changes the asset state from... Updated to , The smart contract writes Updated AM into the blockchain, forming an immutable record of ownership transfer, and simultaneously synchronizes it to the cloud server.

[0169] Step 4: Synchronize metadata with cloud server to achieve lightweight transfer.

[0170] The cloud server only updates the owner identifier and version record in the metadata of the data blocks stored locally, as well as the ciphertext block CT and integrity tag. and PDP verification label All remain unchanged;

[0171] Step 5: Generate an ownership chain to achieve full traceability:

[0172] Smart contracts will record change information for each ownership transfer. Write it into the blockchain to form a transparent and tamper-proof ownership chain.

[0173] In this embodiment, the hash algorithm H used in this solution is uniformly SHA256. The random number Nonce is generated by a pseudo-random number generator according to the NISTSP800-90A specification, with a bit length of 256. The access token τ has a validity period of 1 hour and adopts a single-use validity mechanism. When the token is leaked or the permissions are changed, it will be triggered by the smart contract to become invalid immediately. The transfer type TransferType is divided into four categories: permanent transfer (01), temporary authorization (02), vehicle transaction (03), and institutional sharing (04). Different types correspond to preset asset status conversion rules. The asset status ST includes five categories: active, transferring, transferred, frozen, and cancelled. Precise conversion is achieved by the predefined status conversion function g.

[0174] In this embodiment, the current data owner submits a signed ownership transfer request to a smart contract. After the smart contract completes multi-dimensional verification of identity, signature, and legality, it only incrementally updates the on-chain asset metadata and writes it to the blockchain. At the same time, the cloud server only synchronously updates the owner identifier and version record of the local data block metadata. No modifications are required to the vehicle network encrypted data and various tags. This achieves secure and efficient transfer of data ownership, significantly reducing the computation and communication costs caused by massive data transfer, adapting to the application needs of large-scale vehicle network systems. Furthermore, the blockchain records each ownership change information on the chain, forming a transparent, tamper-proof, and traceable ownership chain. This enables full-process supervision of the data ownership transfer process, while ensuring the confidentiality and integrity of the data during the transfer process. This meets the security and management needs of cross-entity data asset circulation in the context of multi-entity participation in vehicle networks.

[0175] In summary, this invention constructs a vehicle-to-everything (V2X) data management system based on the Hyperledger Fabric blockchain and integrating the CP-ABE encryption mechanism. Relying on smart contracts, it achieves end-to-end on-chain control of asset metadata registration, access permission verification, and ownership transfer. On one hand, it deeply integrates access control and data integrity verification, combined with a verifiable access proof mechanism from a third-party auditing institution, effectively mitigating the risks of cloud data leakage, tampering, and unauthorized access, thus ensuring the confidentiality and integrity of V2X data. On the other hand, during data ownership transfer, only the on-chain asset metadata and the owner identifier and version record in the cloud need to be updated, eliminating the need for repeated encryption and verification tag generation for massive amounts of V2X data. This significantly reduces computation and communication costs and meets the real-time requirements of large-scale V2X systems. Simultaneously, the immutability and traceability of the blockchain ensure that data access behavior and ownership transfer information are transparently recorded on-chain, creating a trustworthy end-to-end regulatory mechanism. This achieves asset-level ownership management and low-cost secure transfer of V2X data assets, meeting the security and regulatory needs for the orderly circulation of high-value V2X data assets with multi-party participation.

[0176] 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 secure transfer of vehicle network data ownership based on blockchain, characterized in that, include: S1: A trusted authorized institution creates a blockchain network based on Hyperledger Fabric and adopts the PoA consensus protocol. In this network, smart contracts with integrated access control functions are deployed, and the CP-ABE encryption mechanism is used to handle access control and ownership transfer of vehicle network data. S2: The car owner registers as a data owner (DO) on the blockchain network. The data owner (DO) encrypts the original data of the vehicle network and uploads it to the cloud server. The cloud server integrates the encrypted data to generate asset metadata, and then completes the confirmation and registration of asset metadata through smart contracts. S3: When a data user DU needs to access vehicle network data, it submits an access request to the smart contract. After the smart contract completes the verification of the data user DU's identity and access permissions, it returns a confirmation result and an access token. The cloud server returns the corresponding asset metadata to the data user DU based on the confirmation result and access token. S4: When the ownership of vehicle network data needs to be transferred from the current data owner to the new data owner, the current data owner submits an ownership transfer request to the smart contract. After the smart contract verifies the legality of the transfer request, it updates the asset metadata and writes it to the blockchain. The cloud server only updates the owner's identifier and version record synchronously, realizing a secure and lightweight transfer of data ownership.

2. The method for secure transfer of vehicle network data ownership based on blockchain according to claim 1, characterized in that, The smart contract includes: registering relevant information of data owners; persistently storing relevant information of all data owners and data users in the blockchain network; storing asset metadata corresponding to vehicle network data and the association information of each data block; granting access permissions to asset metadata; taking data user information and the requested operation as input, determining whether the data user information meets the system's preset requirements; if the conditions are met, granting the corresponding access permissions; and if a legitimate ownership transfer request is received, updating the corresponding asset metadata and writing it into the blockchain.

3. A method for secure transfer of vehicle network data ownership based on blockchain according to claim 2, characterized in that, The process of registering and confirming ownership of asset metadata via smart contracts includes: S21: The vehicle owner completes registration on the blockchain network, becomes the data owner (DO), and obtains a unique identity identifier. Vehicle driving data is divided into multiple data blocks according to preset rules. Each data block is encrypted using the CP-ABE encryption mechanism. Generate ciphertext and integrity label ; S22: Data owner DO will put all encrypted data... and corresponding integrity tags After being uploaded to the cloud server, the cloud server integrates and generates asset metadata (AM), which includes: in, Identifiers representing asset metadata; This indicates the version number and its initial value is 1; Represents a random number. Represents a set of integrity labels The index is used to quickly locate each data block. Tag information; The asset is in a certain state and is initially set to... Activated state; A policy set reference that points to all access policies associated with the asset's metadata; Indicates the timestamp of asset metadata generation; S23: The cloud server uploads the generated asset metadata AM to the blockchain smart contract to complete the registration of ownership of the vehicle network data asset.

4. A method for secure transfer of vehicle network data ownership based on blockchain according to claim 3, characterized in that, Step S3 specifically includes: S31: Data user DU obtains the asset metadata AM of the target vehicle network data from the blockchain network and parses it to obtain the unique asset identifier. and access strategy set reference Generate access request , Represents a timestamp. Represents a random number, and is generated using its own private key. The hash value of the access request information is used to sign the request using the ECDSA algorithm. and the access request and digital signatures Send to the smart contract; Indicates referencing from the access policy set The selected access policy identifier; S32: The smart contract receives an access request from data user DU. With digital signatures Then, the verification algorithm is executed to verify the identity, signature, and access permissions of the data user DU; S33: After successful verification, the smart contract returns the verification result and access token to the data user DU. The data user DU uses the access token to submit a request to the cloud server to obtain the encrypted data. After verifying the validity of the token, the cloud server returns the corresponding encrypted data to the data user DU. If the verification fails, the smart contract directly rejects the data user DU's access request.

5. A method for secure transfer of vehicle network data ownership based on blockchain according to claim 4, characterized in that, Step S4 specifically includes the following steps: S41: Current data owner Construct an ownership transfer request At the same time, using its own private key Sign the hash value of the transfer request information to obtain: in, Indicates the identity of the current data owner; Indicates the transfer type identifier; Represents a random number; Represents a timestamp; Indicate the identity of the new data owner; and submit the transfer request. With digital signatures Send to the smart contract; S42: After receiving the ownership transfer request and digital signature, the smart contract verifies the identity of the current data owner, the signature, and the legality of the transfer request; upon successful verification, the ownership transfer is executed, and the smart contract updates the asset-level metadata. Identify the data owner Replace with the identity of the new data owner and update the version number. At the same time, the updated asset-level metadata will be... Write it into the blockchain network.

6. A method for secure transfer of vehicle network data ownership based on blockchain according to any one of claims 1 to 5, characterized in that, The CP-ABE encryption mechanism comprises three steps: public parameter generation, key generation, and data encryption. Specifically: Step 1: Common Parameter Generation: Trusted Authorization Authority Inputs Security Parameters Generate bilinear group parameters, wherein the bilinear group parameters contain prime numbers of order. group, generator and bilinear pair and randomly select those belonging to The system public key PK and master key MK are calculated from the parameters, thus completing the deployment of global system parameters. Representing prime numbers The non-zero integer field; Step 2: Key Generation: Trusted Authorization Authority AA generates a private key SK for the user based on the user's attribute set S using the master key MK. The private key SK contains relevant keys corresponding to the user's attributes, thus binding the private key to the user's attributes. Step 3: Data Encryption: The data owner (DO) selects the original plaintext data of the vehicle network and constructs ciphertext (CT) using the system public key (PK) in conjunction with the LSSS-based access policy. The ciphertext (CT) contains global ciphertext and components associated with the access policy, enabling fine-grained access control over the vehicle network data. The CP-ABE encryption mechanism also includes a data decryption step: If the decryptor's own attribute set satisfies the access policy associated with the ciphertext, it uses its private key (SK) to perform bilinear pairing calculations and combines the LSSS secret reconstruction method to eliminate redundant components in the ciphertext, ultimately recovering the original plaintext data of the vehicle network and completing attribute-driven conditional decryption.

7. A method for secure transfer of vehicle network data ownership based on blockchain according to claim 1, characterized in that, When data ownership is transferred in step S4, the cloud server only updates the owner identifier and version record in the metadata of the corresponding data block stored locally. The encrypted and integrity tags of the vehicle network data remain unchanged, avoiding repeated encryption and transmission of massive amounts of data. The smart contract writes each change of ownership information of the vehicle network data into the blockchain network, forming a transparent, tamper-proof and traceable ownership chain, realizing full supervision of the data ownership transfer process.

8. A method for secure transfer of vehicle network data ownership based on blockchain according to claim 1, characterized in that, After data user DU obtains the encrypted data, the system combines the integrity tag of the encrypted data with the metadata on the blockchain to generate a verifiable access certificate. The verifiable access certificate is then verified by a third-party auditing institution TPA. Only after the verification is successful can data user DU perform the decryption operation.

9. A method for secure transfer of vehicle network data ownership based on blockchain according to claim 1, characterized in that, Smart contracts write information about every change in ownership of vehicle network data into the blockchain network, forming a transparent, tamper-proof, and traceable ownership chain, enabling full supervision of the data ownership transfer process.

Images