Vehicle data query method and related device

Abstract

The invention discloses a vehicle data query method and a related device, a cloud server is divided into a branch node and a coordination node, the coordination node does not store vehicle data and is responsible for query request verification, authority token generation and query result forwarding, and the branch node stores data and is responsible for query request verification. In the whole query process, verification permissions are not concentrated on a single node, multiple verification of identities and permissions is achieved, the whole vehicle query process is encrypted, the query result is further verified at a user side, and a set of high-security data query method is achieved.

Description

Technical Field

[0001] This invention relates to a vehicle data query method and related apparatus, belonging to the field of data security query. Background Technology

[0002] With the widespread adoption of connected vehicle technology, the interaction between vehicles and the cloud is becoming increasingly intensive, making the cloud a core hub for vehicle data flow. This cloud data not only includes private information such as the owner's travel routes and communication records, but also core data such as vehicle powertrain parameters and safety control logic. It is alarming that if data is tampered with during the query process, it will directly lead to information distortion. Owners may make misjudgments based on incorrect vehicle status data, posing a driving safety hazard. If companies conduct research, development, maintenance, or decision-making based on tampered data, it will also trigger a chain reaction of problems such as technical deviations and resource misallocation, ultimately severely impacting the reliability of the connected vehicle ecosystem and user trust. Currently, there is no highly secure data query method. Summary of the Invention

[0003] This invention provides a vehicle data query method and related apparatus, which solves the problems disclosed in the background art.

[0004] According to one aspect of this application, a vehicle data query method is provided, wherein the method is implemented at a coordination node; wherein the coordination node is any server in the cloud, does not store vehicle data, and is responsible for maintaining the routing of vehicle data reported by branch nodes; the branch node is a cloud server that stores vehicle data, and the vehicle data is stored in the branch node using a Merkle tree. The method includes: In response to receiving a vehicle data query request from the user, the system verifies the vehicle data query request based on the vehicle data routing. In response to the successful verification of the vehicle data query request, the branch node A where the queried vehicle data is located is determined according to the vehicle data route. An authorization token for branch node A is generated by encryption and sent to branch node A. In branch node A, if the authorization token is verified, the queried vehicle data and the hash path of the vehicle data in the Merkle tree are encrypted, and the encrypted query result is fed back to the coordinating node. In response to receiving the query result from branch node A, the query result is fed back to the user client that sent the vehicle data query request; at the user client, the query result is verified.

[0005] Furthermore, vehicle data includes vehicle model and vehicle attribute data; vehicle data routing includes branch node identifiers, vehicle model, vehicle attributes, and user roles with access permissions.

[0006] Furthermore, if the vehicle data S stored in the branch node has multiple routes, the branch node stores the vehicle data S uploaded by multiple routes. When reporting the route of vehicle data S, the vehicle attributes are identified and refined, or all vehicle attribute data are aggregated according to the weight of each route, and the aggregated vehicle attribute data is stored.

[0007] Furthermore, the verification of vehicle data query requests involves verifying whether the user has the authority to query vehicle data.

[0008] Furthermore, digital signatures are performed when generating the authorization token, and the user's public key and the authorization token are also sent when the authorization token is sent. In branch node A, the permission token is verified, including: The authorization token is decrypted using the private key of branch node A, and the digital signature of the authorization token is verified using the public key of the coordinating node.

[0009] Furthermore, in branch node A, the user's public key is used to encrypt the queried vehicle data and the hash path of the vehicle data in the Merkle tree, and a digital signature is performed when encrypting the query result. When the query result is returned, the public key of branch node A is returned. On the user side, the query results are validated, including: The legitimacy of the query result is verified by using the public key of branch node A and the digital signature of the query result. The query result is decrypted using its own private key to verify whether the vehicle data in the query result has been tampered with and whether the hash path is complete.

[0010] Furthermore, the system verifies whether the vehicle data in the query results has been tampered with, including: Calculate the hash value of the vehicle data in the query results. If it matches the corresponding hash value in the hash path, then the vehicle data has not been tampered with.

[0011] Furthermore, the integrity of the hash path is verified, including: The root hash value is calculated layer by layer using the hash path. If it matches the corresponding root hash value stored by the coordinating node, the hash path is complete.

[0012] According to another aspect of this application, a vehicle data query device is provided, wherein the device is mounted on a coordination node; wherein the coordination node is any server in the cloud, does not store vehicle data, and is responsible for maintaining the routing of vehicle data reported by branch nodes; the branch node is a cloud server that stores vehicle data, and the vehicle data is stored in the branch node using a Merkle tree. The device includes: The query request verification module, in response to receiving a vehicle data query request sent by the user, verifies the vehicle data query request according to the vehicle data routing. The permission token module, in response to the successful verification of the vehicle data query request, determines the branch node A where the queried vehicle data is located based on the vehicle data route, encrypts and generates a permission token for branch node A, and sends the permission token to branch node A; wherein, in branch node A, if the permission token is verified, the queried vehicle data and the hash path of the vehicle data in the Merkle tree are encrypted, and the encrypted query result is fed back to the coordinating node. The forwarding module, in response to receiving the query result from branch node A, sends the query result back to the user client that sent the vehicle data query request; at the user client, the query result is verified.

[0013] According to another aspect of this application, a computer-readable storage medium is provided that stores one or more programs, the one or more programs including instructions that, when executed by a computing device, cause the computing device to perform a vehicle data query method.

[0014] The beneficial effects achieved by this invention are as follows: This invention divides the cloud server into branch nodes and coordination nodes. The coordination nodes do not store vehicle data and are responsible for query request verification, permission token generation, and query result forwarding. The branch nodes store data and are responsible for permission token verification and query result generation. In the entire query process, permission verification is not concentrated on a single node, realizing multiple verification of identity and permissions. Furthermore, the vehicle query process is encrypted throughout, and the query results are further verified on the user end, thus realizing a highly secure data query method. Attached Figure Description

[0015] Figure 1 A flowchart for the vehicle data query method; Figure 2 This is a block diagram of a vehicle data query device. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this application or its application or use. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0017] Unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application.

[0018] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0019] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0020] In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0021] It should be noted that similar symbols and letters in the following figures represent similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0022] To address the current lack of highly secure data query methods, this application proposes a novel vehicle data query method, details of which can be found in [link to relevant documentation]. Figure 1 , Figure 1 This is a flowchart of a vehicle data query method provided in an embodiment of this application. The method is mainly implemented in the user terminal, the coordination node, and the branch node. When describing the method, it can be described from the perspective of the coordination node, the user terminal, or the branch node.

[0023] It should be noted that the aforementioned branch nodes are cloud servers for storing vehicle data. Vehicle data can generally include vehicle model and vehicle attribute data. During actual operation, the vehicle data can be uploaded to the cloud based on a predefined protocol, such as through the vehicle intelligent gateway T-Box. Specifically, the vehicle data is fragmented and uploaded to the branch nodes. Merkle trees are used to store the received vehicle data in each branch node. For example, vehicle attribute data is used as leaf nodes and vehicle model is used as parent nodes. The hash value of each leaf and parent node is calculated layer by layer, and finally the root hash is generated and securely stored in the branch node.

[0024] In addition to storing vehicle data, branch nodes are responsible for verifying the permission tokens sent by the coordinating node during queries and encrypting the query results before sending them back to the coordinating node.

[0025] The aforementioned coordination node is a cloud-based server that does not store vehicle data. Typically, one server is selected as the coordination node, responsible for maintaining the vehicle data routes reported by branch nodes. This means recording the nodes where vehicle data is located. The vehicle data routes can include branch node identifiers, vehicle models, vehicle attributes, and user roles with access permissions, etc. The coordination node stores the reported vehicle data routes in the form of a routing table, as shown in Table 1. Simultaneously, the coordination node is also responsible for user authentication and permission token issuance. For example, a subsidiary's R&D personnel may have the right to query attributes such as "vehicle location" and "engine speed" for a particular vehicle model, while sales personnel may only be able to query attributes such as "driving range" and "suggested retail price" for models currently on sale. Furthermore, the coordination node is responsible for forwarding encrypted query results.

[0026] Table 1 Vehicle Data Routing Table

[0027] It should be noted that if the vehicle data S stored in the branch node has multiple routes, and the branch node stores the vehicle data S uploaded by multiple routes, the vehicle attributes are identified and refined when reporting the route of vehicle data S, or all vehicle attribute data are aggregated according to the weight of each route, and the aggregated vehicle attribute data is stored.

[0028] Suppose there are two routes for the battery life data of vehicle C: one uploaded by R&D personnel and the other by after-sales personnel. The coordination node will issue an alert, notifying the branch node storing the data to process it. The processing can be done in the following ways: 1. Store the data uploaded from both routes, but refine the reported vehicle attributes, such as changing them to "Vehicle C_Battery Life_R&D" and "Vehicle C_Battery Life_After-Sales"; 2. Aggregate the data, such as assigning weights based on data reliability or data volume, i.e., route weights, such as the battery life data from the laboratory. Based on high credibility, a weight of 0.8 is assigned. For user feedback on battery life, the sample size is moderate, so a weight of 0.2 is assigned. The aggregated result = R&D result × 0.8 + After-sales result × 0.2, where both results represent battery life. If the difference between two results exceeds a threshold (which can be set to 3 years), such as R&D personnel recording a 6-year battery life for vehicle C and after-sales personnel recording 2 years, a secondary data verification is triggered. Relevant personnel are required to supplement data features, such as the testing environment for R&D data and user usage habits for after-sales data. The routing weights are then readjusted using feature similarity to avoid outliers affecting the results.

[0029] The aforementioned client is a terminal (such as a computer, smartphone, etc.) that needs to query vehicle data, such as a terminal configured by R&D personnel or a terminal configured by sales personnel. The client is responsible for sending vehicle data query requests according to needs, receiving encrypted query results, and verifying the query results.

[0030] Vehicle data in the cloud is stored based on branch nodes and managed and transmitted based on coordination nodes, avoiding the sharing of raw data between nodes, meeting the data storage requirements of different nodes, and achieving efficient data storage, computing and disaster recovery. Furthermore, the coordination node uses data routing to quickly locate the target node (i.e., the branch node where the queried vehicle data is located), reducing the number of cross-node communications. When a node joins or leaves, data can be automatically migrated to ensure that the query path is always valid. It is flexible in expansion and will not significantly increase its own load due to the expansion of data nodes.

[0031] In this implementation, described from the perspective of a coordinating node, the vehicle data query method may include at least the following steps: Step 1: In response to receiving a vehicle data query request from the user, verify the vehicle data query request according to the vehicle data routing.

[0032] It should be noted that vehicle data query requests are sent by the user client based on their needs. For example, if the user client needs to query the battery capacity of vehicle C, they can send a query request to the coordination node by logging into the client.

[0033] In step 1, the coordinating node verifies the vehicle data query request by verifying the query request initiated by the user. Specifically, it can verify whether the user has the necessary permissions to query vehicle data. This can be done by the coordinating node verifying the user and the vehicle data to be queried through a filter. If the user clearly exceeds their permissions, such as a salesperson querying "vehicle location", the node can directly return "insufficient permissions" to the user without proceeding to the next step, thus reducing unnecessary interactions.

[0034] Step 2: In response to the successful verification of the vehicle data query request, the branch node A where the queried vehicle data is located is determined according to the vehicle data route. An authorization token for branch node A is generated by encryption and sent to branch node A. In branch node A, if the authorization token is verified, the queried vehicle data and the hash path of the vehicle data in the Merkle tree are encrypted, and the encrypted query result is fed back to the coordinating node.

[0035] It should be noted that the above vehicle data query request is verified as not exceeding the user's authority. For example, if the user queries the battery capacity of vehicle C without exceeding the user's authority, the coordinating node will determine the branch node A where the battery capacity of vehicle C is located based on the vehicle data routing table. The coordinating node will then use the public key of branch node A to encrypt and generate an authorization token for branch node A. The authorization token includes the user ID and role, the vehicle data to be queried, and the validity period (e.g., 1 hour). A digital signature is also performed when encrypting and generating the authorization token, that is, the SM2 algorithm is used to attach the coordinating node's signature. Finally, the authorization token, the user's public key, and the coordinating node's public key are sent to branch node A.

[0036] The user's public and private keys (i.e., key pairs), as well as the public and private keys (i.e., key pairs) of branch nodes and coordinating nodes, are pre-generated. When a user logs into the client, public and private keys are generated using security tools (such as the key management tool associated with the SSO system) based on the user's input ID and password, and stored in a secure area on the client. Similarly, when branch nodes and coordinating nodes start up, they generate key pairs locally using cryptographic algorithms (such as RSA and ECC). The private key can be stored using hardware security modules or software encryption. After generating key pairs, branch nodes and users bind their public keys and identity identifiers (such as "Node 3" and "User ID=XXXX") and submit them to the coordinating node.

[0037] It should be noted that in branch node A, the authorization token is verified by decrypting the authorization token with the private key of branch node A and verifying the digital signature of the authorization token with the public key of the coordinating node, so as to verify the validity period of the authorization token and the sender of the token.

[0038] After receiving the request from the coordinating node, branch node A completes all data processing locally, including decrypting and verifying the permission token. That is, it decrypts the permission token with branch node A's private key, verifies the coordinating node's signature with the coordinating node's public key, confirms the token's validity period, and confirms that the user has the right to query vehicle data, such as the battery capacity of vehicle C.

[0039] If the verification is successful, vehicle data is read from the local database, such as reading the battery capacity of vehicle C = 50kWh. The leaf node hash value H1 corresponding to the query data is located, and a hash path from H1 to the root hash value H3 is generated. The queried vehicle data (i.e., 50kWh) and the hash path of the vehicle data in the Merkle tree are encrypted using the user's public key. When encrypting the query result, the branch node's private key is used to digitally sign it. The digitally signed and encrypted query result, along with the branch node A's public key, is fed back to the coordinating node.

[0040] Step 3: In response to receiving the query result from branch node A, the query result is fed back to the user terminal that sent the vehicle data query request; wherein, on the user terminal, the query result is verified.

[0041] It should be noted that in step 3, the coordinating node mainly plays the role of forwarding, that is, directly forwarding the feedback result of branch node A to the client.

[0042] On the user side, verifying the query results mainly involves using the public key of branch node A and the digital signature of the query results to verify the legality of the query results, that is, to confirm that the query results come from the branch node, to decrypt the query results using its own private key, to verify whether the vehicle data in the query results has been tampered with, and to verify whether the hash path is complete.

[0043] Verifying whether the vehicle data in the query results has been tampered with mainly involves: calculating the hash value of the vehicle data in the query results; if it matches the corresponding hash value in the hash path, then the vehicle data has not been tampered with.

[0044] Assuming we have 50kWh and a hash path, the user calculates the hash value H11 of "50kWh" and compares it with H1 in the hash path. If they match, it means the vehicle data has not been tampered with.

[0045] Verifying the completeness of the hash path mainly involves: calculating the root hash value H33 layer by layer using the hash path; if it matches the corresponding root hash value H3 stored by the coordinating node, then the hash path is complete.

[0046] The above method divides the cloud server into branch nodes and coordination nodes. The coordination nodes do not store vehicle data but are responsible for query request verification, authorization token generation, and query result forwarding. The coordination nodes store data and are responsible for authorization token verification and query result generation. Throughout the query process, authorization verification is not centralized on a single node, achieving multi-factor authentication of identity and permissions. Furthermore, the entire vehicle query process is encrypted, and the query results are further verified on the user's end, implementing a highly secure data query method. See Figure 2 , Figure 2 This is a block diagram of a vehicle data query device provided in an embodiment of this application. The device is a virtual device, and like the method, it is mainly loaded and implemented in the user terminal, the coordination node, and the branch node.

[0047] The aforementioned branch nodes are servers that store vehicle data in the cloud, so a first storage module is set up on the branch nodes; the coordination nodes are servers that do not store vehicle data in the cloud, and are responsible for maintaining the routing of vehicle data reported by the branch nodes, so a second storage module is set up on the coordination nodes.

[0048] In this embodiment, described from the perspective of a coordinating node, the apparatus may include at least: The query request verification module, in response to receiving a vehicle data query request from the user, verifies the vehicle data query request based on the vehicle data routing.

[0049] The permission token module responds to the successful verification of the vehicle data query request, determines the branch node A where the queried vehicle data is located based on the vehicle data route, encrypts and generates a permission token for branch node A, and sends the permission token to branch node A.

[0050] It should be noted that in branch node A, after the permission token verification is successful, the queried vehicle data and the hash path of the vehicle data in the Merkle tree are encrypted, and the encrypted query result is fed back to the coordinating node; therefore, a permission token verification and feedback module is set up in branch node A.

[0051] The forwarding module, in response to receiving the query result from branch node A, sends the query result back to the user client that sent the vehicle data query request.

[0052] It should be noted that on the user side, query result verification primarily involves using the public key of branch node A and the digital signature of the query result to verify its legitimacy. This includes confirming that the query result originates from the branch node, decrypting the result using the user's own private key, verifying whether the vehicle data in the query result has been tampered with, and verifying the integrity of the hash path. Therefore, a data verification module is included on the user side.

[0053] It should be noted that the aforementioned permission token is generated by encryption based on the public key of branch node A, and the permission token is decrypted based on the private key of branch node A. The encrypted query result uses the user's public key, and the decrypted query result uses the user's private key.

[0054] The user's public and private keys (i.e., key pairs), as well as the public and private keys (i.e., key pairs) of the branch nodes and the coordinating node, are pre-generated. When a user logs into the client, public and private keys are generated using security tools (such as the key management tool associated with the SSO system) based on the user's input ID and password, and stored in a secure area on the client. Similarly, when the branch nodes and the coordinating node start up, they generate key pairs locally using cryptographic algorithms (such as RSA and ECC). The private keys can be stored using hardware security modules or software encryption. After generating key pairs, the branch nodes and users bind their public keys and identity identifiers (such as "Node 3" and "User ID=XXXX") and submit them to the coordinating node. Therefore, a third key pair generation and storage module is set up on the user's end, a second key pair generation and storage module is set up on the coordinating node, and a first key pair generation and storage module is set up on the branch nodes. The public key submitted to the coordinating node can be directly stored in the second storage module.

[0055] The aforementioned device includes a branch node side device, a coordination node side device, and a user terminal device. It solves the security and privacy challenges in distributed vehicle data querying through a closed-loop process of local query—encrypted transmission—hash verification.

[0056] This application also relates to a computer-readable storage medium that stores one or more programs, the one or more programs including instructions that, when executed by a computing device, cause the computing device to perform a vehicle data query method.

[0057] This application also relates to a computer device including one or more processors and one or more memories, wherein one or more programs are stored in the one or more memories and configured to be executed by the one or more processors, and the one or more programs include instructions for performing a vehicle data query method.

[0058] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0059] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0060] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0061] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0062] The above are merely embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of the claims of the present invention pending approval.

Claims

1. A vehicle data query method, characterized by, The method is implemented in a coordination node; wherein the coordination node is any server in the cloud, does not store vehicle data, and is responsible for maintaining vehicle data routes reported by branch nodes; the branch node is a cloud server that stores vehicle data, and the branch node uses a Merkle tree to store vehicle data; The method comprises: In response to receiving a vehicle data query request sent by a user end, verifying the vehicle data query request according to a vehicle data route; In response to the vehicle data query request being verified, determining a branch node A where the queried vehicle data is located according to the vehicle data route, generating an authorization token of the branch node A by encryption, and sending the authorization token to the branch node A; wherein in the branch node A, the queried vehicle data and the hash path of the vehicle data in the Merkle tree are encrypted under the condition that the authorization token is verified, and the encrypted query result is fed back to the coordination node; In response to receiving the query result fed back by the branch node A, the query result is fed back to the user end that sent the vehicle data query request; wherein in the user end, the query result is verified.

2. The method of claim 1, wherein, The vehicle data comprises vehicle type and vehicle attribute data; the vehicle data route comprises branch node identification, vehicle type, vehicle attribute, and user roles with access rights.

3. The method of claim 2, wherein, If the vehicle data S stored by the branch node exists in multiple routes, the branch node stores vehicle data S uploaded by multiple routes, identifies and refines vehicle attributes when reporting vehicle data S routes, or aggregates all vehicle attribute data according to the weight of each route, and stores the aggregated vehicle attribute data.

4. The method of claim 1, wherein, Verifying the vehicle data query request is to verify whether the user has the right to query the vehicle data.

5. The method of claim 1, wherein, When the authorization token is generated by encryption, a digital signature is performed, and the public key of the branch node A and the public key of the user are also sent when the authorization token is sent. In the branch node A, the authorization token is verified, comprising: The authorization token is decrypted by using the private key of the branch node A, and the digital signature of the authorization token is verified by using the public key of the coordination node.

6. The method of claim 5, wherein, In the branch node A, the queried vehicle data and the hash path of the vehicle data in the Merkle tree are encrypted by using the public key of the user, and the query result is digitally signed when the query result is encrypted, and the public key of the branch node A is fed back when the query result is fed back. In the user end, the query result is verified, comprising: The legality of the query result is verified by using the public key of the branch node A and the digital signature of the query result, the query result is decrypted by using the private key of the user end, whether the vehicle data in the query result is tampered with is verified, and whether the hash path is complete is verified.

7. The method of claim 6, wherein, Whether the vehicle data in the query result is tampered with is verified, comprising: The hash value of the vehicle data in the query result is calculated, and if it is consistent with the corresponding hash value in the hash path, the vehicle data is not tampered with.

8. The method of claim 6, wherein, Whether the hash path is complete is verified, comprising: The root hash value is calculated layer by layer by using the hash path, and if it is consistent with the corresponding root hash value saved by the coordination node, the hash path is complete.

9. A vehicle data query apparatus characterized by comprising: The device is loaded in a coordination node; wherein the coordination node is any server in the cloud, does not store vehicle data, and is responsible for maintaining vehicle data routing reported by branch nodes; the branch node is a cloud server storing vehicle data, and the vehicle data is stored in the branch node by using a Merkle tree; The device comprises: A query request verification module, which verifies a vehicle data query request sent by a user end according to vehicle data routing in response to receiving the vehicle data query request; A permission token module, which determines a branch node A where the queried vehicle data is located according to the vehicle data routing, generates a permission token of the branch node A by encryption, and sends the permission token to the branch node A in response to the vehicle data query request verification passing; wherein in the branch node A, the queried vehicle data and a hash path of the vehicle data in the Merkle tree are encrypted under the condition that the permission token verification passes, and the encrypted query result is fed back to the coordination node; A forwarding module, which feeds back the query result to the user end sending the vehicle data query request in response to receiving the query result fed back by the branch node A; wherein the query result is verified in the user end.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores one or more programs, and the one or more programs include instructions which, when executed by a computing device, cause the computing device to perform the method of any one of claims 1-8.

Images