Decentralized vehicle starting permission verification method and system based on homomorphic encryption and threshold secret sharing

Abstract

This invention discloses a vehicle start permission verification method, system, and vehicle based on a dual-blockchain architecture, belonging to the fields of vehicle security and blockchain technology. This invention decouples permission verification and start authorization through a dual-blockchain architecture: During system initialization, a vehicle master key is generated and divided into N key fragments, each bound to a homomorphically encrypted value of one of the user's N verification factors. The master key hash is stored in the first blockchain, and the verification fragment pairs are stored in the second blockchain. During vehicle start verification, the user provides M verification factors, which are homomorphically encrypted and submitted to the second blockchain for ciphertext matching. If a match is successful, the corresponding key fragment is returned. The vehicle reconstructs the master key and calculates its hash, submitting it to the first blockchain for comparison. Upon successful comparison, a start token is obtained, enabling vehicle start. This invention achieves decentralized, privacy-preserving permission verification, supports dynamic threshold verification, and provides fully auditable evidence storage.

Description

Technical Field

[0001] This invention relates to the fields of vehicle security, identity authentication, and blockchain technology, and specifically to a method, system, and vehicle for verifying vehicle startup permissions in a decentralized, auditable, and privacy-preserving manner by utilizing dual blockchains, homomorphic encryption, and threshold secret sharing technology. Background Technology

[0002] With the development of intelligent connected vehicles and shared mobility, keyless vehicle start systems have been widely adopted. Current mainstream keyless start solutions typically rely on a centralized cloud server to verify user identity (such as digital keys, biometrics, or PIN codes), and then directly send a start authorization command to the vehicle upon successful verification. This centralized architecture has inherent flaws: 1) Single point of failure and vulnerability: If the central server is attacked or malfunctions, the entire service will be paralyzed; 2) Strong coupling between verification and authorization: Attackers may illegally start vehicles through man-in-the-middle attacks, replay attacks, or by forging server commands; 3) Privacy leakage risk: Sensitive data such as user biometrics is centrally stored on the server, making it an easy target for attacks; 4) Rigid policies and lack of auditing: The verification logic is fixed by the server, making it difficult to support dynamic policies, and the entire verification and authorization process lacks immutable third-party records, hindering post-event traceability and accountability.

[0003] Blockchain technology, with its decentralized, immutable, and traceable characteristics, offers a new approach to solving the aforementioned problems. Existing research has explored storing vehicle identity, key hashes, and other data on the blockchain, but the trust and privacy issues inherent in the verification process itself have not been completely resolved. Most solutions place the complete verification logic or user plaintext data on the blockchain, resulting in bottlenecks in performance, privacy, and flexibility.

[0004] Therefore, there is an urgent need in this field for a new vehicle start permission verification solution that can decouple verification and authorization logic, protect user privacy, have flexible verification capabilities, and provide trusted auditing. Summary of the Invention

[0005] This invention aims to overcome the shortcomings of existing technologies and provide a vehicle start permission verification method, system, and vehicle based on a dual-chain architecture. This achieves complete decoupling of permission verification and vehicle start authorization, fundamentally eliminating the possibility of illegally starting the vehicle by forging verification signals. Simultaneously, it protects user privacy and security, improves the decentralized robustness of the system, and provides a reliable audit trail for the entire permission lifecycle. To achieve the above objectives, this invention adopts the following technical solution:

[0006] Firstly, this invention provides a vehicle startup permission verification method based on a dual-chain architecture. The process will be described below from the system initialization and permission registration stage and the vehicle startup verification and authorization stage.

[0007] System initialization and permission registration phase:

[0008] Step 1: A trusted organization generates and publishes the homomorphic public key required by the system. Its corresponding private key It is securely managed by this organization.

[0009] Step 2: Generate a unique vehicle startup master key for the specific vehicle. and utilize Threshold secret sharing algorithm will use the master key Divided into Key fragmentation .

[0010] Step 3: Calculate the master key hash value and vehicle identification Related storage on the first blockchain middle.

[0011] Step 4: Collect data from target users Validation factors .

[0012] Step 5: Use homomorphic encryption public key Regarding the Each verification factor is encrypted to obtain... One encryption verification factor .

[0013] Step Six: For each encryption verification factor With one of the key fragments Perform one-to-one binding to form Each verification fragment pair .

[0014] Step 7: Place the above Each verification segment matches the vehicle identifier. Related storage on the second blockchain middle.

[0015] Vehicle startup verification and authorization phase:

[0016] Step 1: In response to the user's vehicle start request, collect the information provided by the user. One validation factor, in .

[0017] Step 2: Use homomorphic encryption public key For this collection Each verification factor is encrypted to obtain M encrypted verification factors. .

[0018] Step 3: Encrypt the... Each verification factor is submitted to the second blockchain. smart contracts .

[0019] Step 4: The smart contract, in its encrypted state, will submit the encrypted verification factor. Corresponding cryptographic verification factor stored on the blockchain Perform homomorphic matching calculations to verify user identity.

[0020] Step 5: If at least (t is a preset threshold) If the verification factors match successfully, the smart contract will bind the key shards to these successfully matched factors. Return the information to the vehicle.

[0021] Step Six: The vehicle terminal collects at least [data / information] locally. After valid key fragmentation, the master key candidate value is recovered using the threshold secret sharing reconstruction algorithm. .

[0022] Step 7: Calculation hash value and submit it to the first blockchain. smart contracts To make a ruling.

[0023] Step 8: The first blockchain Smart contract comparison With pre-stored on the chain If they match, a valid start-up ruling token is generated and returned. .

[0024] Step 9: The vehicle controller verifies the start-up ruling token. The validity of the verification is confirmed, and the vehicle start operation is performed after successful verification.

[0025] Step 10: Generate an audit log containing key information such as the startup request, verification results, authorization decision, and timestamp, and upload it to the second blockchain. Record the evidence.

[0026] Secondly, the present invention provides a vehicle start permission verification system based on a dual-chain architecture for implementing the above method, the system comprising:

[0027] Trusted Center: As the authoritative body for system initialization, it is responsible for generating and managing the system's fundamental cryptographic parameters. It is also responsible for configuring the first blockchain. Second blockchain The initial parameters.

[0028] User terminal: Used for registering users and collecting user verification factors.

[0029] Vehicle controller: Built into the vehicle, it is responsible for triggering the verification process, interacting with the blockchain, reconstructing the master key locally, verifying the ruling result, and ultimately controlling the vehicle to start.

[0030] First Blockchain Smart contracts are deployed. It is used to securely store the master key hash and provide final, tamper-proof authorization decisions.

[0031] Second Blockchain Smart contracts are deployed. It is used to securely store "verification shard pairs" and provide privacy-preserving authentication services based on homomorphic encryption.

[0032] Service node: During the initialization phase, it is responsible for generating the master key, performing secret splitting, binding verification factors, and calling the smart contract to complete the data upload to the blockchain. After the system is running, it can degenerate into an observer node or an auditor. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of a vehicle startup permission verification system based on a dual-chain architecture provided in an embodiment of the present invention. The diagram shows a Trusted Center (TA), a service node, a user terminal, a vehicle controller, and a first blockchain. and the second blockchain Core components, etc.

[0034] Figure 2 This is a flowchart illustrating the system initialization and permission registration phases provided in an embodiment of the present invention.

[0035] Figure 3 This is a flowchart illustrating the vehicle startup verification and authorization phase provided in an embodiment of the present invention. Detailed Implementation

[0036] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0037] Example 1:

[0038] I. System Architecture

[0039] Reference Figure 1 The system in this embodiment includes the following core components:

[0040] Trusted Institution Nodes (TAs): Operated by industry consortia or regulatory bodies, equipped with a Hardware Security Module (HSM), responsible for generating and securely hosting system-level cryptographic parameters, including homomorphic encryption key pairs. The random source for generating the master key and the initialization parameters for configuring the blockchain.

[0041] User terminal: The smartphone of the vehicle owner or authorized user, with a dedicated APP installed, used to collect and encrypt verification factors in a secure environment and interact with the service provider to complete permission registration.

[0042] Vehicle Controller: A security control unit built into the vehicle that supports a Trusted Execution Environment (TEE). It is responsible for triggering the verification process, interacting with the blockchain, locally reconstructing the master key, and controlling the vehicle startup.

[0043] First Blockchain A strongly consistent consortium blockchain with deployed smart contracts. It is used to store the master key hash and provide final, tamper-proof authorization ruling services.

[0044] Second Blockchain A high-performance consortium blockchain with deployed smart contracts. It is used to store "verification shard pairs" and provide privacy-preserving verification services based on homomorphic encryption.

[0045] Service Node: The back-end system of the car manufacturer or mobility service provider, responsible for processing user registration requests, calling TA services, completing key sharding and binding of verification factors, and calling smart contracts to complete data uploading to the blockchain.

[0046] II. System Initialization and Permission Registration Phase

[0047] The goal of this phase is to provide specific vehicles and car owner Establish startup permissions and securely deploy the relevant credentials on the dual-chain architecture. The specific process is as follows: Figure 2 As shown:

[0048] S101: Trusted Organization Initialization: The Trusted Organization (TA) generates homomorphic encryption key pairs in an offline environment. .in, As public system parameters, they are written into constants in the verification management smart contract and the permission adjudication smart contract, and are pre-installed in user terminals and vehicle controllers through secure channels. It is then securely stored in the TA's HSM and is only enabled in a very few necessary audit scenarios to ensure that sensitive information such as user biometrics cannot be decrypted by any single entity.

[0049] S102: User terminal verification factor collection: The user enters N=5 verification factors sequentially on the user terminal, such as... , , .

[0050] S103: User terminal authentication factor encryption: using a public homomorphic encryption key. Each of these five factors is encrypted to obtain the encrypted verification factor. to The encryption process employs encryption algorithms that support additive or multiplicative homomorphism. These homomorphic encryption algorithms satisfy the following fundamental properties:

[0051] For additive homomorphisms .

[0052] For multiplicative homomorphisms .

[0053] in Represents a homomorphic encryption function. This is a homomorphic addition operation. This is a homomorphic multiplication operation. , This is plain text.

[0054] S104: Master Key Generation and Sharding: After initiating a registration request, the user sends the encryption factor to the service provider. Upon receiving the request, the service provider (calls TA's secure random number generation service) to generate a 256-bit strong random master key for this authorization. Subsequently, the (t, N) threshold secret sharing algorithm is used to segment K. In this embodiment, the threshold t=3 and the total number of segments N=5. For example, the Shamir secret sharing algorithm is used.

[0055] Construct a polynomial of degree t-1 (i.e., degree 2): .

[0056] in, = , and The coefficients are randomly selected. Given a publicly known large prime number. By selecting N distinct non-zero values ​​of x (e.g., x = 1, 2, 3, 4, 5), N partitions are calculated. In this embodiment, the five generated fragments are denoted as... Any three fragments can be combined to reconstruct the polynomial f(x) using Lagrange interpolation, thereby recovering the master key K.

[0057] S105: Decision information is uploaded to the blockchain: The service provider calculates the master key. hash value (e.g., using the SHA-256 algorithm), and calling the first blockchain. Smart contracts on key-value pairs Write it onto the blockchain.

[0058] S106: Verification information is uploaded to the blockchain: The service provider will receive 5 encrypted verification factors from the user's terminal. The 5 key fragments in step S104 Perform one-to-one binding to form verification shard pairs: , , , , The service provider then invoked the second blockchain. Smart contracts on Vehicle identification These five verification shard pairs are stored on the blockchain in the form of a Merkle tree or a list of key-value pairs. At this point, the permission registration phase is complete, and user terminals can securely delete locally stored encrypted verification factors.

[0059] II. Vehicle Start-up Verification and Authorization Phase

[0060] The goal of this phase is to enable vehicle owners to obtain authorization and start the vehicle from the dual-chain system by providing partial verification factors when they need to use the vehicle. The specific process is as follows: Figure 3 As shown:

[0061] S201: Triggering the verification process: The vehicle owner enters the vehicle and presses the "Start" button. The vehicle controller wakes up and prompts the user to provide verification factors via the in-vehicle screen or voice prompt.

[0062] S202: User-provided verification factors: To adapt to the current scenario, the car owner provided the following 3 factors (M=3, threshold t=3): .

[0063] S203: Local Encryption and Submission: The vehicle controller uses a pre-configured homomorphic encryption public key within the local TEE environment. For the collected Encrypt each one separately to obtain , , Subsequently, the vehicle controller constructs a verification request, including the vehicle identifier. And three encryption factors, and submit them to the second blockchain. smart contracts .

[0064] S204: On-chain privacy verification: smart contracts Upon receiving the request, execute the following logic:

[0065] 1. According to Query the list of verification shard pairs stored on the chain.

[0066] 2. For each encryption factor submitted by the user The smart contract links it to the corresponding location on the chain. Perform homomorphic matching calculations. Taking facial features as an example, if the extracted features are represented as vectors, Euclidean distance or cosine similarity under homomorphic encryption can be used for calculation. The matching degree is calculated using homomorphic properties, and a match is determined according to preset ciphertext comparison rules. If a match is successful, the key shard index corresponding to that factor is recorded.

[0067] 3. Count the number of successfully matched factors. In this example, assume... and Match successful. and Match successful. and Match successful, a total of 3 matches.

[0068] S205: Return key fragment: Since the number of successful matches (3) has reached the preset threshold t=3, the smart contract Read the key fragments bound to the three successful verification factors from the chain. It is sent to the vehicle controller.

[0069] S206: Local Key Reconstruction: In the TEE environment, the vehicle controller uses the three received fragments. The threshold secret sharing reconstruction algorithm is executed. Specifically, the Lagrange interpolation formula is used.

[0070]

[0071] in This is the fragment value. Substituting the publicly available large prime number used in the Shamir secret sharing algorithm into x=0 yields the candidate value for the master key. If the fragmentation is correct, Should be consistent with the original master key Totally consistent.

[0072] S207: Initiating a ruling request: Vehicle controller calculation and call the first blockchain Smart contracts on ,submit As a request for a ruling.

[0073] S208: On-chain adjudication: smart contract according to The initialization phase storage was retrieved. and with the received Compare:

[0074] 1. If both match, it indicates that the vehicle has successfully reconstructed the correct master key, and authentication is successful. The smart contract generates a start authorization token containing the vehicle identifier, timestamp, random number, and signed with the contract's private key. And send it as the function return value to the vehicle controller.

[0075] 2. If there is a discrepancy, an authorization denial message will be returned.

[0076] S209: Startup Execution: The vehicle controller receives and verifies the start authorization token. After verifying the validity and expiration of the digital signature, a start command is sent to the vehicle to connect the high-voltage power or start the engine.

[0077] S210: Audit Log Preservation: After startup, the vehicle controller will store the complete audit log of this startup (including VID, timestamp, factor type used, and first blockchain). Transaction ID, Second Blockchain Package the transaction ID (and other relevant information) and send it to the second blockchain. The audit log storage interface can be used to directly write the logs of the two blockchains as events, thus achieving full-process traceability.

Claims

1. A vehicle startup permission verification method based on a dual-chain architecture, characterized in that, include: Permission registration steps: Generate a vehicle start master key, divide the master key into multiple key fragments, and store the hash value of the master key in the first blockchain. Collect multiple verification factors from the user, encrypt the verification factors using a homomorphic encryption public key, bind the encrypted verification factors one by one with the multiple key fragments to form multiple verification fragment pairs, and store them in the second blockchain. ; Permission verification steps: In response to the startup request, collect the verification factors provided by the user in the second blockchain. The verification factor provided in encrypted form is subjected to homomorphic matching verification; in response to successful verification, the data is retrieved from the second blockchain. Obtain the corresponding key fragment; reconstruct the master key candidate value using at least one obtained key fragment; submit the hash value of the master key candidate value to the first blockchain. Perform a comparison; if the comparison matches, authorize the vehicle to start.

2. The method according to claim 1, characterized in that, In the permission registration step, the master key is divided into N key fragments using a threshold secret sharing algorithm. The minimum number of fragments required to reconstruct the master key is preset to be t, where t ≤ N. In the permission verification step, the number of verification factors provided by the user is M, where t ≤ M ≤ N. The number of key fragments obtained must reach t in order to successfully reconstruct the candidate value of the master key.

3. The method according to claim 2, characterized in that, In the second blockchain The homomorphic matching verification further includes: determining whether the number of successfully matched verification factors reaches or exceeds the preset threshold t.

4. The method according to claim 1, characterized in that, The verification factor includes at least one of biometric factors, cryptographic credentials, and device identifiers.

5. The method according to claim 1, characterized in that, In the second blockchain Homomorphic matching verification is performed on the smart contracts deployed on it. Execute the smart contract It supports homomorphic matching calculations between verification factors provided in ciphertext and encrypted verification factors stored on-chain without decryption.

6. The method according to claim 1, characterized in that, The hash value of the master key candidate value is submitted to the first blockchain. The comparison is performed by the smart contracts deployed on it. The smart contract is also used to generate and return a digitally signed activation authorization credential upon matching.

7. The method according to claim 6, characterized in that, Before the authorized vehicle is started, the procedure also includes a step of verifying the validity of the start authorization certificate.

8. The method according to claim 1, characterized in that, It also includes an auditing step: generating an audit log containing key information about the startup event, and storing the audit log in the first blockchain. middle.

9. The method according to claim 1, characterized in that, The permission registration step further includes: generating and securely managing homomorphic encryption key pairs by a trusted center, wherein the public key in the homomorphic encryption key pair is used to encrypt the verification factor, and the private key is securely managed by the trusted center.

10. A vehicle start permission verification system based on a dual-chain architecture, characterized in that, The system for implementing the method as described in any one of claims 1-9 comprises: The Trusted Center is used to generate and manage system cryptographic parameters and is responsible for configuring the blockchain. and The initial parameters; User terminal, used to collect and provide user verification factors; The vehicle controller, located inside the vehicle, is used to respond to start requests, interact with the blockchain, locally reconstruct the master key, and control the vehicle to start. First Blockchain It is used as the adjudication chain and has smart contracts deployed on it. It is used to store the master key hash value and provide authorization decisions; Second Blockchain It serves as a verification chain and is equipped with smart contracts. It is used to store verification shard pairs and provide authentication services; The service node is used to process permission registration requests, generate master keys, perform secret splitting, bind verification factors and key shards, and call smart contracts to complete data uploading to the blockchain.

11. The system according to claim 10, characterized in that, The vehicle controller includes a trusted execution environment for reconstructing master key candidate values ​​in a secure environment.

12. A vehicle, characterized in that, This includes the vehicle controller as described in claim 10 or 11.

13. A non-volatile computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-9.

Images