OTA security upgrading method based on VIN and domain control traceability code dynamic binding

Abstract

The invention relates to the technical field of automobile network security and software upgrading, in particular to an OTA security upgrading method based on VIN and domain control traceability code dynamic binding, which comprises the following steps: writing a traceability code into a domain controller; the cloud platform initializes and binds a VIN code and a traceability code of the domain controller; the vehicle end agent reports the VIN code and the traceability code state regularly; the cloud platform dynamically checks whether the current VIN code and the traceability code are consistent with the binding record or not; if the verification succeeds and the vehicle state is detected to be normal, the cloud platform initiates OTA upgrade; and the cloud platform inquires the upgrade package accurately matched with the binding relation and issues the upgrade package to the domain controller for installation verification. According to the technical scheme, upgrading is accurate and safe, accurate binding of the'vehicle-hardware 'level is achieved, the mistaken upgrading risk caused by hardware replacement is eradicated, and the function safety is greatly improved.

Description

An OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code Technical Field

[0001] This invention relates to the field of automotive network security and software upgrade technology, specifically to an OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code. Background Technology

[0002] Current automotive OTA upgrades, especially those for core domain controllers (such as the smart cockpit domain and intelligent driving domain), generally employ a VIN-based upgrade authorization strategy. However, existing technology has significant drawbacks:

[0003] 1. Insufficient binding granularity: The VIN code only identifies the vehicle, not the specific hardware inside the vehicle. If the domain controller of the vehicle is replaced due to after-sales maintenance, the cloud cannot detect this change, which may lead to the flashing of an incompatible old software version to the new hardware, causing functional safety risks.

[0004] 2. Static Binding Risk: Traditional VIN-ECU binding relationships are usually static. Once the binding information is cracked or leaked, attackers may clone VIN and ECU information and illegally reprogram a large number of vehicles.

[0005] 3. Lack of hardware change traceability: The cloud cannot effectively record and verify the replacement history of key hardware components inside the vehicle, making it impossible to dynamically adjust the upgrade strategy according to the actual hardware status, resulting in a disconnect between after-sales maintenance and OTA upgrade management. Summary of the Invention

[0006] The purpose of this invention is to provide an OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code, achieving more refined, secure, and traceable OTA upgrade control. Specifically, the objectives are as follows:

[0007] 1. Provide a strong binding method based on VIN code and domain controller hardware traceability code to ensure that the upgrade package is accurately matched with the current hardware status of the vehicle.

[0008] 2. Establish a dynamically updated binding mechanism that can automatically update the cloud binding relationship and trigger reauthorization when critical vehicle hardware changes (such as replacing the domain controller) to prevent unauthorized upgrades.

[0009] 3. Build a traceable hardware change log system to provide decision support for OTA upgrade strategies and improve upgrade security and reliability.

[0010] To achieve the above objectives, this application employs the following technical solution:

[0011] An OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code includes the following steps:

[0012] S1. Write the traceability code to the domain controller;

[0013] S2. Initialize the binding of VIN code and domain controller traceability code on the cloud platform;

[0014] S3. Vehicle-side agents regularly report the status of VIN codes and traceability codes;

[0015] S4. The cloud platform dynamically verifies whether the current VIN code, traceability code, and binding record are consistent.

[0016] S5. Verification successful, and vehicle status detected as normal. The cloud platform initiates OTA upgrade.

[0017] S6, the cloud platform queries and matches the exact upgrade package with the binding relationship and sends it to the domain controller for installation and verification.

[0018] Furthermore, the traceability code in step S1 is a multi-level code, including a basic information segment, a production information segment, a unique serial number, and a cryptographic digest.

[0019] Furthermore, the traceability code in step S1 is either burned onto the non-erasable memory within the domain controller on the production line or generated and protected by a security chip.

[0020] Furthermore, the vehicle-side agent in step S3 is a gateway or a T-Box.

[0021] Furthermore, step S5 also includes a verification failure, whereby the cloud platform locks the OTA upgrade function of the VIN and triggers the after-sales process.

[0022] Furthermore, after the after-sales process verifies and updates the binding relationship on the cloud platform, and resolves the lock, the cloud platform generates a new hardware change record.

[0023] The beneficial effects of this invention are:

[0024] 1. The upgrade of this technical solution is precise and safe, achieving precise binding at the "vehicle-hardware" level, eliminating the risk of accidental upgrades due to hardware replacement, and greatly improving functional safety.

[0025] 2. This technical solution employs a dynamic verification mechanism, which ensures that even if the VIN code is cloned, the upgrade request will be rejected because the traceability code it is bound to does not match the cloud record, effectively defending against hardware cloning attacks.

[0026] 3. This technical solution establishes a "digital twin" record of the vehicle's hardware configuration, providing clear data support for after-sales service, fault diagnosis, and recall tracing.

[0027] 4. This technical solution automates the re-authorization process after hardware changes, reducing manual intervention and lowering operation and maintenance costs. Attached Figure Description

[0028] Figure 1 is a flowchart of the overall process of this invention. Detailed Implementation

[0029] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings. The following embodiments are merely exemplary and can only be used to explain and illustrate the technical solution of the present invention, and should not be construed as limiting the technical solution of the present invention.

[0030] The key to the technical solution of this application lies in assigning a unique and unchangeable hardware traceability code to each major domain controller of the vehicle. This code is dynamically bound to the VIN code in the cloud and serves as an important basis for OTA upgrade authorization.

[0031] The systems required for this technical solution include an OTA cloud platform, a vehicle-side agent (gateway or T-Box), and at least one main domain controller.

[0032] The OTA cloud platform includes an upgrade management server, a dynamic binding relationship database, and a traceability code verification service. This database not only stores VINs but also associates and stores the traceability codes, software versions, and binding history of each domain controller.

[0033] Primary domain controller: Internally stores a unique hardware traceability code. This code can be programmed onto non-erasable memory (such as eFuse) on the production line, or generated and protected by a security chip (HSM). The code contains information such as hardware model, production batch, and unique serial number.

[0034] The vehicle-side agent in this application, such as a gateway or T-Box, is responsible for reporting the current VIN code and the traceability code of each domain controller when the vehicle starts up or communicates with the cloud periodically.

[0035] An OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code. This method includes three core stages: binding relationship initialization, dynamic verification, and security upgrade. Specifically, it includes the following steps:

[0036] S1. Write the traceability code to the domain controller; In this embodiment, the traceability code is a hardware traceability code, which is a multi-level code, including a basic information segment for identifying the hardware model (such as "ADCU2024-A"); a production information segment for identifying the production batch, date, and other information; a unique serial number, which is the globally unique serial number of the domain controller; and a cryptographic digest, which is the digest value obtained by hashing the above information to prevent tampering.

[0037] S2. Initialize the binding of VIN code and domain controller traceability code on the cloud platform after the vehicle is taken off the production line.

[0038] S3. Vehicle-side agents regularly report the status of VIN codes and traceability codes;

[0039] S4. The cloud platform dynamically verifies whether the current VIN code, traceability code, and binding record are consistent.

[0040] S5. Verification successful, and vehicle status detected as normal. The cloud platform initiates OTA upgrade.

[0041] S6, the cloud platform queries and matches the exact upgrade package with the binding relationship and sends it to the domain controller for installation and verification.

[0042] In this application, step S5 also includes a verification failure, whereby the cloud platform locks the OTA upgrade function of the VIN and triggers the after-sales process. After verification in the after-sales process, the binding relationship on the cloud platform is updated, the lock is resolved, and the cloud platform generates a new hardware change record.

[0043] The above are preferred embodiments of the present invention. The basic principles and advantages of the present invention have been shown and described above. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are only illustrative of the principles of the present invention. Various changes and modifications can be made to the present invention without departing from the spirit and scope of the present invention. All such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. An OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code, characterized in that, Includes the following steps: S1. Write the traceability code to the domain controller; S2. The cloud platform initializes the binding of the VIN code and the domain controller's traceability code; S3. The vehicle-side agent periodically reports the status of the VIN code and traceability code; S4. The cloud platform dynamically verifies whether the current VIN code and traceability code are consistent with the binding record; S5. If the verification is successful and the vehicle status is detected as normal, the cloud platform initiates an OTA upgrade; S6. The cloud platform queries the binding relationship to match the exact upgrade package and sends it to the domain controller for installation verification.

2. The OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code according to claim 1, characterized in that, The traceability code in step S1 is a multi-level code, including a basic information segment, a production information segment, a unique serial number, and a cryptographic digest.

3. The OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code according to claim 2, characterized in that, The traceability code in step S1 is either burned into the non-erasable memory in the domain controller on the production line or generated and protected by a security chip.

4. The OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code according to claim 1, characterized in that, The vehicle-side agent in step S3 is either a gateway or a T-Box.

5. The OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code according to claim 1, characterized in that, Step S5 also includes verification failure, cloud platform locking the OTA upgrade function of the VIN and triggering after-sales process.

6. The OTA security upgrade method based on dynamic binding of VIN and domain controller traceability code according to claim 1, characterized in that, After the after-sales process is verified, the binding relationship on the cloud platform is updated and the lock is resolved. The cloud platform then generates a new hardware change record.

Images