Method and system for data exchange with a vehicle diagnostic request source

Abstract

The present application relates to the field of telecommunications, and particularly to guaranteeing secure data exchange when diagnosing a vehicle. A method for a vehicle to exchange data with a diagnosis request source and a system for implementing the method are provided. The method includes: generating a unique diagnosis session key in the vehicle for each electronic control unit (ECU) in the vehicle that has a factory diagnosis session key, and replacing the factory diagnosis session key of the ECU with the generated unique diagnosis session key; setting routing rules for diagnosis requests and responses; when a diagnosis request is received, first verifying the unique diagnosis session key for the ECU to which the request is directed, and if the verification is passed, routing the received diagnosis request according to information of the vehicle and its components and the routing rules; and when a response to the diagnosis request is received, routing the response according to information of the vehicle and its components and the routing rules. The present application provides improved diagnosis session control and enhanced security of data exchange.

Description

Technical Field

[0001] This invention relates to the field of telecommunications, and more particularly to ensuring secure data exchange during vehicle diagnostics.

[0002] Secure diagnostic session management for electronic control units (ECUs, also referred to as ECUs in the accompanying diagram) is crucial for modern transportation systems. With the development of communication and automation technologies in the transportation and logistics sectors, ensuring secure communication between external diagnostic tools and vehicle ECUs is becoming increasingly important for preventing unauthorized access, data theft, cyberattacks, and ensuring the safety and reliability of the vehicle itself and the entire transportation system. Background Technology

[0003] One of the most widely used protocols in the field of vehicle diagnostics is the Unified Diagnostic Service (UDS, ISO 14229), which aims to ensure secure data transmission between vehicle control units and diagnostic tools. The primary goal of UDS is to ensure that only authorized devices and users can access critical functions and data within the vehicle. To achieve this, UDS implements an authentication mechanism using a so-called "seed key" method. According to the seed key method, the Electronic Control Unit (ECU) sends a unique identifier ("seed") to the diagnostic tool, which must then use a secret algorithm to generate the correct "key" based on this identifier. Only after successful key verification is the ECU allowed access to protected functions and data.

[0004] In the current environment, due to the increasing frequency of data exchange and the growing connectivity between vehicles and various devices and networks, the security of data exchange via UDS faces numerous risks, such as unauthorized access, data tampering, and attacks using forged credentials.

[0005] Currently, methods for ensuring the security of vehicle diagnostic data exchange, such as the scheme disclosed in US11165851B2, provide basic access control for communications via UDS through the use of secure access mechanisms. However, the proposed methods lack robust protection mechanisms against various emerging cyber threats, and certain risks exist in practical applications, such as the possibility of connections bypassing the UDS manager.

[0006] Access control during the diagnostic process plays a crucial role in ensuring vehicle safety. In UDS, different types of sessions (levels) exist to manage diagnostic communications. Each data exchange session has its specific purpose and access level. The UDS standard (ISO 14229) specifies four main diagnostic session types, each corresponding to different access levels and purposes. The Default Session (0x01) is a basic session that is active upon startup of the Electronic Control Unit (ECU). It allows standard diagnostic operations such as reading fault codes (DTCs), acquiring sensor data, and general system information. This session does not provide access to sensitive or modifiable data (such as software or configuration). The Extended Session (0x03) provides access to additional functions not available in the Default Session. Under this session, actuator testing, data writing to memory, and in-depth diagnostic procedures can be performed. Sometimes, working under this session requires additional authentication or security authorization. The Programming Session (0x02) is dedicated to updating the ECU's software. It allows secure and authorized changes to the device's memory or firmware. This session typically requires strict adherence to security protocols, including authentication and key exchange. The Manufacturing Session (0x04) is used by the manufacturer during the assembly or product release phase to configure and test control units. It provides access to specialized commands and functions not available in normal operating mode. Working under this session also requires a high level of security and is typically limited to the factory environment. These sessions are managed through Diagnostic Session Control (0x10), which allows session switching to be performed only when necessary security conditions and access restrictions are met.

[0007] Each type of session is activated by using the Diagnostic Session Control Service (0x10) and specifying the corresponding sub-function identifier. Switching between sessions must adhere to security conditions and ensure proper synchronization of communication. Furthermore, those skilled in the art will understand that switching between sessions has a significant impact on vehicle safety, requiring specific conditions to be met to ensure safety and prevent unauthorized operation of the vehicle and its components.

[0008] Furthermore, diagnostic session keys are used for efficient and secure diagnostics of up to approximately two hundred electronic control units (ECUs) in modern vehicles. These keys allow for different levels of access to ECU functions and parameters, enabling mechanics and maintenance personnel to perform tasks such as diagnostics, calibration, software updates, and troubleshooting. The confidentiality of diagnostic session keys is particularly important for original equipment manufacturers (OEMs), as it relates to warranty service, the commercialization of diagnostic services, and the activation of additional functions offered to vehicle equipment. If a diagnostic session key is compromised, numerous vehicles containing components from the same batch are at risk, as these components are typically assigned the same factory diagnostic session key. An attacker could use the compromised key to establish diagnostic data exchange sessions with these components. Under such a vulnerability, it is possible to obtain confidential ECU data, modify calibration parameters, reprogram the unit, etc., which would significantly reduce vehicle security and potentially lead to unauthorized modifications to vehicle functions.

[0009] Therefore, ensuring secure data exchange during vehicle diagnostics not only helps improve vehicle maintenance and operational safety, but also creates additional opportunities for vehicle manufacturers to commercialize their products.

[0010] This invention takes into account existing challenges in the field of vehicle safety and aims to eliminate current vulnerabilities and defects. Summary of the Invention

[0011] The core of the technical solution of this invention lies in establishing a control and routing mechanism for diagnostic requests and their responses within the vehicle.

[0012] According to one aspect of the present invention, a method for a vehicle to exchange data with an external diagnostic request source is provided. The method includes: generating a unique diagnostic session key for each electronic control unit (ECU) in the vehicle that has a factory-issued diagnostic session key, and replacing the factory-issued diagnostic session key of the ECU with the generated unique diagnostic session key; setting routing rules for diagnostic requests and responses; when a diagnostic request is received, first verifying the unique diagnostic session key for the ECU to which the diagnostic request is directed, and if the verification is successful, routing the received diagnostic request according to information about the vehicle and its components and the routing rules; when a response to the diagnostic request is received, routing the response similarly according to information about the vehicle and its components and the routing rules.

[0013] According to some embodiments of the present invention, the routing rules include at least the following information: whether there is an open diagnostic session with the requested ECU; whether there is currently permission and / or authorization to send a diagnostic request; whether the source of the diagnostic request is authorized to send a diagnostic request to the requested ECU; whether there are restrictions on routing the diagnostic request and its response based on an identifier indicating a vehicle information security threat; and whether there are restrictions on routing the diagnostic request and its response based on the vehicle location.

[0014] According to some embodiments of the present invention, the information of the vehicle and its components takes into account at least the following factors: whether there is an active user with a specific role in the vehicle, whether the vehicle is in a drivable state, whether the vehicle is in a driving state, and whether there is an identifier indicating a threat to vehicle information security.

[0015] According to some embodiments of the present invention, the identifier indicating a vehicle information security threat is information indicating at least one of the following: the number of diagnostic requests per unit time exceeds a preset threshold; the time interval between diagnostic requests is less than a preset threshold; the time interval between a diagnostic request and a response is less than a preset threshold; a diagnostic request after a sudden change in location; a diagnostic request issued by a diagnostic device connected to OBD-II when the vehicle is off; a diagnostic request issued by a third-party application through a session with the vehicle infotainment system; or a diagnostic request issued after an accident.

[0016] According to some embodiments of the present invention, the routing rules are based on the status information of the vehicle and its components.

[0017] According to some embodiments of the present invention, if the received diagnostic request or response does not have a corresponding routing rule set, the received diagnostic request or response is rejected.

[0018] According to some embodiments of the present invention, the routing rules are updated upon receiving a corresponding instruction.

[0019] According to some embodiments of the present invention, the unique diagnostic session key generated for each electronic control unit (ECU) of the vehicle is encrypted and backed up by key derivation so that it can be restored when needed.

[0020] According to another aspect of the invention, a system for data exchange between a vehicle and a diagnostic request source is provided. The system includes at least one processor and at least one storage device, and is configured to: connect to an in-vehicle network of the vehicle; generate a unique diagnostic session key for each electronic control unit of the vehicle and store the unique diagnostic session key in encrypted form; replace the existing diagnostic session key of the electronic control unit with the generated unique diagnostic session key; receive and route diagnostic requests and responses according to set routing rules and information about the vehicle and its components; and store the set routing rules.

[0021] According to some embodiments of the present invention, the proposed system is configured to: back up the unique diagnostic session key generated for each electronic control unit (ECU) of the vehicle, and request and obtain the backup of the diagnostic session key via a network.

[0022] According to some embodiments of the present invention, the proposed system is further configured to perform the backup in encrypted form via key derivation so that it can be restored when needed.

[0023] The proposed system and method can control and route diagnostic requests from different sources and directed to vehicle components, and offer enhanced vehicle data exchange security. As described below, this invention provides a configurable and secure data exchange control mechanism within a diagnostic session framework, which, as those skilled in the art know, offers extensive capabilities to alter the state of the vehicle and its components. Attached Figure Description

[0024] Other objects, features, and advantages of the present invention will become apparent from the following description of embodiments with reference to the accompanying drawings, wherein:

[0025] Figure 1 This demonstrates the application of the invention in a vehicle.

[0026] Figure 2 This paper demonstrates a process for replacing the factory diagnostic session key of an ECU according to one embodiment of the present invention.

[0027] Figure 3 An example flow of a backup operation is shown according to one embodiment of the present invention.

[0028] Figure 4 The process of replacing an ECU according to one embodiment of the present invention is illustrated.

[0029] Figure 5 The process of replacing a security gateway unit according to one embodiment of the present invention is illustrated.

[0030] Figure 6An algorithm for processing routing requests is shown according to one embodiment of the present invention.

[0031] Figure 7A This paper presents a first example scenario for diagnosing session routing and control according to one embodiment of the present invention.

[0032] Figure 7B A second example scenario for diagnosing session routing and control is shown according to one embodiment of the present invention.

[0033] Figure 8 A working example of the proposed system is shown, in which the diagnostic control module handles requests from both remote and local diagnostic devices.

[0034] Figure 9 A working example of the proposed system is shown, in which the diagnostic control module handles requests from remote diagnostic devices (in an extended session) and local diagnostic devices (in a default session).

[0035] Figure 10 A working example of the proposed system is shown, in which the diagnostic control module handles requests from remote diagnostic devices for ECU#2 and ECU#3, as well as requests from a local diagnostic device (in the default session) for ECU#1.

[0036] Figure 11 A working example of the proposed system is shown, in which the diagnostic control module blocks requests to ECU#1 from the local diagnostic device.

[0037] Figure 12 Another working example of the proposed system is shown, in which the diagnostic control module blocks requests to ECU#1 from the local diagnostic device.

[0038] Figure 13 A working example of the proposed system is shown, in which the diagnostic control module prevents a request from the local diagnostic device to switch to the Programming Session to access ECU#1.

[0039] Figure 14 A working example of the proposed system is shown, in which the diagnostic control module rejects a request from the IVI diagnostic device to switch to the Programming Session for ECU#1.

[0040] Figure 15 An example of the most general operational procedure of the method according to the present invention is shown.

[0041] Figure 16 Examples of vehicles in which at least a portion of the invention is implemented, or by means of such vehicles, are shown. Detailed Implementation

[0042] The objects and features of the present invention, as well as the methods for achieving these objects and features, will become apparent from reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, which can be implemented in various forms. The description provided is intended to help those skilled in the art to fully understand the present invention, the scope of which is defined only by the appended claims.

[0043] As used in this specification, the term "vehicle" refers to any vehicle that includes at least one in-vehicle communication network and at least one electronic control unit (ECU). Furthermore, the examples described with respect to specific vehicle implementations (such as automobiles) are intended to illustrate one possible implementation of the invention, but in no way limit the application of the invention to other vehicles not directly mentioned in this specification. Examples of vehicles in which at least a portion of the invention is implemented, are... Figure 16 The vehicle shown.

[0044] The term "vehicle network" as used in this specification can refer to a wired or wireless network, and includes at least some of the devices located within the vehicle.

[0045] The present invention supplements existing standards and protocols, thus ensuring compatibility with various existing standards and protocols without affecting the achievement of technical effects. As a non-limiting example, in the specific application of the invention to automobiles, the receipt of requests can be implemented according to the MQTT (Message Queuing Telemetry Transport) protocol specification, interaction with the ECU via the CAN (Controller Area Network) bus can be implemented according to the UDS (Unified Diagnostic Services) protocol, and interaction with the Vehicle Security Operations Center (VSOC) can be organized using the TLS (Transport Layer Security) protocol with CEF (Common Event Format). The protection mechanisms for diagnostic equipment, the proposed security gateway, and the transmission protocols between at least one vehicle ECU are not the focus of this specification; however, in typical implementations, various solutions can be employed to protect transmission protocols (such as CAN and DoIP (Diagnostic Over Internet Protocol)), for example, using SecOC (Secure On-board Communication) and TLS respectively.

[0046] All operations of the method according to the first aspect of the invention and the functions of the system according to the second aspect of the invention can be implemented either by multiple components of the vehicle or in a single unit. For ease of understanding of the concept of the invention, the concept of "Security Gateway" is used below to refer to the aforementioned set of components or the aforementioned single unit, referred to as "SGW system" in the drawings, and mentioned in some examples and embodiments.

[0047] The examples given also use terminology based on the UDS communication standard, which is well known to those skilled in the art, but is not intended as an example of limiting the implementation of communication between vehicle components and various external components.

[0048] Unless otherwise stated, all elements of the same type, even if they have different numbers in different drawings, do not have any substantial difference from each other in order to implement the present invention.

[0049] Figure 1 The schematic diagram illustrates the role of the invention in vehicle 110 and shows various entities that may participate in data exchange. Those skilled in the art will understand that the figures only show examples of different types of such entities based on the most common current systems; however, in practical applications, both the connection type and the devices themselves may differ, which does not affect the effectiveness of the invention.

[0050] like Figure 1 As shown, according to an exemplary embodiment of the present invention, vehicle 110 may include multiple ECUs 160 and be able to exchange data with external devices such as external diagnostic device 141, remote server 170, and external fake diagnostic device 151. Meanwhile, the vehicle 110's own communication network also includes the security gateway SGW 120 proposed in this invention, an IVI (In-Vehicle Infotainment) system 180 (in-vehicle infotainment system, i.e., dedicated software and / or devices for managing vehicle multimedia and infotainment systems, which may also be used for diagnostics in some cases), and certain internal fake diagnostic devices 152.

[0051] It is important to emphasize that there is a potential possibility that diagnostic session establishment requests may originate from multiple devices, including components of vehicle 110 and third-party devices exchanging data with it, and the access rights these requests intend to obtain for vehicle 110 may exceed their proper authorized scope. As those skilled in the art know, there is so-called local diagnostics, where diagnostic device 141 is directly connected to the On-Board Diagnostics II (OBD-II) system or directly to the CAN bus. Furthermore, there is so-called cloud diagnostics, where diagnostic requests are received from a remote server 170 via the Internet. Simultaneously, there is also internal diagnostics, where the IVI system 180 or another unit of vehicle 110 acts as a diagnostic device, which... Figure 1 The term is represented as diagnostic device-application 143 within the IVI system 180. Therefore, this invention is applicable not only to ensuring security when receiving diagnostic requests during diagnostic activities, but also broadly to ensuring security during data exchange with vehicles. The proposed diagnostic request control and routing mechanism enables more secure data exchange with vehicles.

[0052] According to the present invention, in order to exchange data with various diagnostic request sources, a security gateway system (SGW system 120) is proposed to be implemented in vehicle 110. For example... Figure 1 As shown, data exchange with diagnostic devices is achieved through this system. Any diagnostic request first arrives at the SGW system 120, and only after processing by the SGW system 120 can the request be routed to the requested ECU, rejected, or blocked. Simultaneously, according to the present invention, the SGW system 120 is also responsible for controlling and routing responses to diagnostic requests, which further enhances the security of data exchange with the source of the diagnostic request. To clearly illustrate that all diagnostic requests pass through the SGW system 120, the internal diagnostic device 142 is shown in the figure. To improve the reliability of diagnostic request source verification, the SGW system 120 is designed to generate a unique diagnostic session key within the vehicle 110 for each ECU 160 and replace the factory-issued diagnostic session key with the generated key.

[0053] As those skilled in the art will understand, the SGW system 120 may also typically have other functions related to data exchange and security of the vehicle 110 that are not covered in this specification. Figure 1 One embodiment is shown, in which the functionality of the SGW system 120 according to the present invention is presented in the form of a diagnostic control module 130. However, this embodiment is given only for clarity and does not constitute the only possible structure for data exchange participants according to the present invention.

[0054] Therefore, as Figure 1As shown, according to the present invention, the possibility of direct data exchange between the ECU 160 of vehicle 110 and devices capable of sending diagnostic requests to the ECU 160 (e.g., remote server 170, external diagnostic device 141, diagnostic device-application 143, external fake diagnostic device 151, internal fake diagnostic device 152) is eliminated. According to the present invention, the aforementioned devices can only send diagnostic requests to the ECU 160 of vehicle 110 through the proposed SGW system 120. Furthermore, the system for data exchange proposed according to the present invention improves the security of data exchange through its control and routing mechanisms for diagnostic requests and their responses.

[0055] Replace the factory diagnostic session key for the ECU

[0056] During vehicle production, numerous ECUs from different suppliers are used. The initial initialization of each ECU is completed by its direct manufacturer using a default key set. The term "diagnostic session key," or simply "key," may be used below to refer to the diagnostic session key. It is important to understand that in practice, a key set consisting of a certain number of keys may be used, such as preparing one key for each of four different diagnostic sessions, forming a key set containing four keys. In the examples in the specification, when "ECU key" or "ECU key set" is mentioned, it refers to the complete diagnostic key set for different access levels. These keys may be released in batches or as an entire device series and may be considered to be at risk of leakage, posing a threat to vehicle security. According to the present invention, the factory key used for the diagnostic session is replaced before confirming that the vehicle is ready (entering product mode).

[0057] Figure 2This demonstrates an example workflow for regenerating a diagnostic session key (replacing the initialization key) for the ECU as a unique key within the vehicle before confirming vehicle readiness (entering product mode). Through diagnostic device 210, a command is sent to SGW system 220 in step 240 to generate a new diagnostic session key for vehicle control unit ECU 230. SGW system 220 then initiates the key replacement process: first, in step 250, a new, vehicle-unique key is generated for ECU#1 and encrypted and stored in a storage device (in one embodiment, the decryption key is stored in the Trusted Platform Module (TPM) on the SGW system 220 motherboard); then, in step 251, the existing factory diagnostic session key is used to unlock it, and a diagnostic session is initiated. Within this session, in step 252, the newly generated diagnostic session key is written to ECU#1. Subsequently, SGW system 220 locks ECU#1 in step 253 and deletes its stored factory diagnostic session key for ECU#1 in step 254. The diagnostic session key replacement process described above for ECU#1 (steps 250-254) also applies to other electronic control units ECU#2, ECU#3...ECU#N (steps 255-259). After completing the key replacement for all electronic control units, the SGW system 220 sends a write status report to the diagnostic device 210 in step 260 to confirm that the diagnostic session key replacement operation was successful.

[0058] The present invention proposes to generate a unique diagnostic session key for the electronic control unit within the vehicle and replace the easily leaked factory diagnostic session key, which can improve vehicle security and reduce the possibility of unauthorized access to the vehicle within the diagnostic session framework even if the factory diagnostic session key has been leaked.

[0059] exist Figure 2 In the implementation shown, a sequential loop is implemented (steps 250-254 are performed first, and then repeated). However, if the technical conditions permit, a parallel mode can also be used to replace keys for different units.

[0060] according to Figure 2 In the illustrated implementation, the functions of generating a unique diagnostic session key, establishing a diagnostic session using the factory key, and replacing the factory diagnostic session key are all implemented in the SGW system 220 for vehicle security data exchange. However, as previously stated, the system proposed according to the present invention can be implemented either within one or two units comprising at least one processor and at least one storage device, or through a combination of different vehicle components, as long as these components are capable of performing the functions proposed in the present invention. In the examples below, "SGW system unit" refers to a set of components capable of implementing the described SGW system functions.

[0061] Those skilled in the art will understand that, within the scope of this invention, various mechanisms can be implemented to ensure that the SGW system 220 can obtain the initial factory diagnostic session key, and the SGW system 220 itself can have various interface implementations. For example, according to some embodiments of the invention, the factory key can be imported from the ECU manufacturer's remote server in a secure format (e.g., the SGW system 220 provides a secure key loading interface using application-layer encryption, and the encryption key is protected based on hardware protection at a level no lower than FIPS 140-3).

[0062] Following key replacement, in some implementations, an additional key backup procedure is provided for subsequent recovery if needed—for example, if the SGW system unit is implemented as a physically independent component of the vehicle, recovery is performed when that unit is replaced. In one possible implementation, the backup of the ECU key should be stored in encrypted form in the backup system, and the system operator should not be able to access the plaintext key. For this purpose, in one implementation, a key derivation scheme is used. In some implementations, this can be done using, for example, a dedicated Key Derivation Function (KDF), which converts one or more encryption keys or secrets into another key or secret while maintaining the necessary cryptographic strength. The backup system generates and stores its local Import Key (IK), which should be unique for each SGW unit. This Import Key IK is sent to the SGW system unit upon request from the SGW system before encrypting the ECU key backup for a specific vehicle. In a preferred implementation, this key is not used directly for encryption; instead, it is used as part of the encryption key derived together with the SGW system's internal Security Key (SK). According to different embodiments of the present invention, the SK key can be the same for SGW system units of the same generation, or multiple keys can be pre-built into the unit, or updated in the event of a leak. To determine which key the SGW system specifically used when creating a backup, metadata containing the index of the required key is required.

[0063] Figure 3 An example flow of a backup operation according to one embodiment of the present invention is shown. In this embodiment, an ECU diagnostic session key backup process is demonstrated, involving backup system 310, SGW system 320, and vehicle safety operation center VSOC 330.

[0064] In step 340, the backup system 310 receives a request to start backup from the SGW system 320 and initiates the backup process for the ECU diagnostic session key. First, in step 341, the backup system 310 creates an import key IK that will be used during the encryption process. The import key IK ensures the secure handling of the backup data. In step 342, the generated import key IK is sent from the backup system to the SGW system 320. This key is used to obtain the backup key (BK). In step 343, the SGW system 320 uses the import key IK received from the backup system and its own SK key (a unique key stored in the SGW system 320's internal secure storage device) to obtain the backup key BK. The backup key BK is used as the encryption key for the ECU diagnostic session key.

[0065] Subsequently, in step 344, the SGW system 320 creates a backup of the ECU diagnostic session key. This ensures that the current ECU key is preserved for later use. In step 345, the SGW system 320 encrypts the backup of the ECU diagnostic session key using the backup key BK. Encryption protects the backup from unauthorized access. Then, in step 346, the encrypted backup (containing relevant metadata, such as timestamps and key-related data) is sent to the backup system 310. The metadata helps to identify and verify the backup when needed.

[0066] In step 347, the backup system 310 saves the encrypted backup, the import key IK, and related metadata to ensure the integrity and traceability of the saved backup. In step 348, the backup system 310 sends a status update to the SGW system 320, confirming that the encrypted backup has been successfully saved. Furthermore, according to the presented implementation, the SGW system 320 sends a security event notification to the VSOC in step 349. This security-critical operation is logged for monitoring and detection of any suspicious activity.

[0067] According to some implementations, the backup system 310 is located in the cloud infrastructure.

[0068] Those skilled in the art will also understand that every ECU in the vehicle not connected to the SGW system constitutes a vulnerability and reduces the effectiveness of the invention. The invention achieves its maximum effect when all existing ECUs in the vehicle are fully covered by the control and routing area of ​​the requests and responses proposed in this invention.

[0069] According to some embodiments of the present invention, the key can also be changed upon request from the diagnostic device. In this process, according to some embodiments of the present invention, the new key is generated directly in the SGW system, then the ECU is unlocked using the factory diagnostic session key, and the newly generated key is set using UDS communication. According to some embodiments of the present invention, backup and recovery keys are implemented individually for each unit in each vehicle. Therefore, if the backup system is located in a cloud infrastructure, the cloud infrastructure needs to support indexing the key backup and associating it with a vehicle identifier (e.g., for a car, this could be the Vehicle Identification Number (VIN)) and all its ECU units (each ECU unit has a unique number). In such an implementation, it is possible to prevent an unauthorized ECU unit from being illegally moved from one vehicle to another for use.

[0070] According to some embodiments of the present invention, some ECU units implement an interface for processing diagnostic session keys, which helps to simplify the replacement of these ECU units or devices and systems containing such ECUs.

[0071] According to one embodiment of the present invention, each ECU's diagnostic session key is allowed to be replaced only once, and thereafter any replacement of the diagnostic session key is prohibited. Any attempt to rewrite the key will be recorded as a security event or as an identifier indicating a vehicle information security threat. In some implementations of this function, if the connection with the Vehicle Safety Operations Center (VSOC) is interrupted, the SGW system must ensure the confidentiality of the key during storage, including protection against attacks on physical access devices (e.g., preventing the removal of external storage and reading of its contents).

[0072] According to a preferred embodiment of the present invention, the only mechanism for deriving the diagnostic session key from the SGW system is to back up the key to a backup system in encrypted form.

[0073] According to one embodiment of the present invention, when backing up the key to the backup system, the key is encrypted using the backup system's unique key, and the backup system provides an interface for exporting the key in a secure format to the ECU manufacturer's cloud.

[0074] Replace ECU

[0075] According to the present invention, when installing a new ECU in a vehicle, product mode initialization is required, which is achieved through pre-production preparation. Within the framework of the present invention, pre-production preparation includes replacing the factory diagnostic session key with a diagnostic session key unique to the vehicle. Furthermore, according to the present invention, the concept is not to use the key of the replaced ECU, but to generate and install a new key for the new ECU. Figure 4 The procedure for replacing an ECU is illustrated according to one embodiment of the present invention. It is assumed that the new ECU 430 has been successfully connected to the vehicle communication network and uses a standard (factory) diagnostic session key (provided by the manufacturer). Figure 4 The flowchart shown illustrates the interaction between the diagnostic device or remote diagnostic interface 410, SGW system 420, ECU 430, and Vehicle Safety Operations Center (VSOC) 440 to achieve secure communication and manage ECU diagnostic session keys, according to one embodiment of the present invention.

[0076] First, the diagnostic device or remote diagnostic interface 410 initializes communication in step 450 by unlocking the SGW system 420. During this process, the SGW system 420 sends the corresponding security event data to the Vehicle Safety Operations Center (VSOC) 440 in step 451 (as previously mentioned, according to some embodiments of the invention, if the connection to the VSOC 440 is temporarily interrupted, the data to be sent to the VSOC 440 is ensured to be securely stored). It should be noted here that the security event recording described in the above example is specific to a particular implementation of the invention and is consistent with the security strategy in that case. Therefore, in other implementations, the set of event types considered as security events may differ from those given in this example. The recording of security events at least ensures that any important operations related to the ECU security key are recorded and monitored.

[0077] SGW system 420 is actually a security layer used to restrict unauthorized access to the vehicle's ECU 430. Unlocking SGW system 420 is permitted when performing diagnostic or update operations that comply with security policies.

[0078] Then, in step 452, a command is sent to the SGW system 420 to write a data identifier (DID) for changing the ECU key (default value). The diagnostic device 410 writes the DID to the SGW system 420, indicating a request to change the ECU key to the default value. This is typically used to reset the ECU key during initial setup or key recovery. According to the described implementation, this event is also considered a security event and is reported to the VSOC 440 in step 453.

[0079] Subsequently, in step 454, the SGW system 420 attempts to unlock the ECU 430, whose diagnostic session key is about to be replaced, using the factory diagnostic session key. After successfully unlocking the ECU 430, it is locked in step 455 to prevent unauthorized modifications during this process. In step 456, the ECU's factory diagnostic session key is saved as the active (current) diagnostic session key, ensuring that the SGW system 420 possesses a valid key for temporary secure operation.

[0080] Subsequently, diagnostic device 410 checks the key status of ECU 430 in step 457 to confirm the existence of a valid key. SGW system 420 confirms the completion of the aforementioned steps in step 458 and sends a status indicating successful unlocking of ECU 430 using the current key to diagnostic device 410. Diagnostic device 410 initiates the generation of new diagnostic session keys for ECU 430 in step 459; these keys are unique to each ECU 430 in the vehicle. This is a key operation in implementing the invention, forming a secure closed loop by replacing the original factory key with a new key. According to the described embodiment, SGW system 420 then sends a security event notification to VSOC 440 again in step 460 to record and monitor this operation affecting vehicle safety.

[0081] In step 461, the SGW system 420 generates a new diagnostic session key for the ECU 430, and in step 462, it unlocks the ECU 430 using the currently active diagnostic session key to enable the writing of the newly generated diagnostic session key. In step 463, the new diagnostic session key is written to the ECU 430, and then in step 464, the ECU 430 is locked to prevent further unauthorized access. Subsequently, in step 465, the SGW system 420 updates the active diagnostic session key information for the ECU 430. This step completes the security key replacement process, after which the SGW system 420 sends a key write status report to the diagnostic device 410 in step 466 to confirm successful completion of the operation. According to the described embodiment, a security event notification is then sent to the VSOC 440 in step 467 to record the completion of the diagnostic session key generation and rewriting process.

[0082] Replace Security Gateway (SGW)

[0083] If the SGW system functionality proposed according to this invention is implemented in a replaceable (hardware or software) module, then its replacement operation can also be considered. Figure 5 An example of an operation procedure is provided. According to... Figure 5 The illustrated embodiment of the present invention shows that the process of replacing the SGW system 520 module involves data exchange between the diagnostic tool 510, the SGW system 520, the ECU 530, the backup system 540, and the Vehicle Safety Operations Center (VSOC) 550.

[0084] The new SGW system 520 module is delivered in initialization mode and has the default factory diagnostic session key for the ECU units. It needs to restore the current keys for each unit from the backup system 540; otherwise, it will be unable to start any diagnostic sessions or verify its authenticity in SecOC communication. According to Figure 5The scenario shown assumes that the new SGW system 520 module has been successfully connected to the vehicle communication network.

[0085] Figure 5 The process begins at step 560, whereby the diagnostic device or system connects to and unlocks the SGW system 520 module. In step 561, the SGW system 520 module sends security event data to the VSOC 550 (as previously described, according to some embodiments of the invention, if the connection to the VSOC 550 is temporarily interrupted, the data to be sent to the VSOC 550 is securely stored).

[0086] After unlocking, diagnostic device 510 sends a command to SGW system 520 in step 562, instructing it to begin restoring the ECU key from backup. According to the described implementation, SGW system 520 module reports this event to VSOC 550 in step 563, sending a security event and notifying that the key recovery process has begun.

[0087] Subsequently, in step 564, the SGW system 520 module requests the encrypted ECU key backup, related metadata, and import key IK stored in the backup system 540. In response to the request, the backup system 540 sends the encrypted ECU key backup, import key IK, and corresponding metadata (such as timestamps and identifiers) in step 565.

[0088] In step 566, the SGW system 520 module uses the security gateway's SK key, the provided import key IK, and metadata to calculate a backup key BK, which is used as the encryption key for the ECU diagnostic session key. After obtaining the backup key BK, the SGW system 520 module uses the BK key in step 567 to decrypt the encrypted ECU diagnostic session key backup. This step ensures the recovery of the original ECU diagnostic session key. Subsequently, the SGW system 520 module updates its ECU diagnostic session key information using the keys recovered from the backup, and in step 568 sets these keys as the currently active diagnostic session key.

[0089] Subsequently, the following operations are performed for each ECU 530 cycle (steps 569-571) to verify the key recovery status: Step 569 – Unlock ECU 530 using the current (new) diagnostic session key; Step 570 – Check access permissions to ECU 530 using the current key; and Step 571 – Lock ECU 530 after inspection.

[0090] Subsequently, the SGW system 520 module saves the key recovery and verification status in step 572, and according to the described implementation method, sends a final security event to the VSOC 550 in step 573 to record the completion of the key recovery process.

[0091] After the above operations are completed, if the diagnostic tool 510 checks the diagnostic session key status of the ECU 530 in step 574 to confirm that the recovery is successful, the SGW system 520 module sends the recovery and verification status to the diagnostic device 510 in step 575.

[0092] Therefore, according to the replacement process of the SGW system 520 module described above, secure communication and recovery of diagnostic session keys can be ensured for all ECUs in the vehicle, key events can be recorded for VSOC monitoring, and verification can be performed to confirm that the ECU diagnostic session keys are functioning normally.

[0093] Configure diagnostic request routing rules

[0094] According to the present invention, another component of the diagnostic request control and routing mechanism is the diagnostic request routing rule. The routing rule is a crucial component of the routing and control mechanism, defining access permissions based on existing information about the data exchange participants, the vehicle, and its components. Typically, the routing rule is set based on security requirements and business scenarios, containing information that enables the most effective implementation of specific security policies for incoming diagnostic requests and ECU-issued request responses, and the efficient application of these security policies.

[0095] Therefore, according to some implementation methods, routing rules contain at least the following information: - Are there other diagnostic devices already having a higher access level diagnostic session open? - Whether the vehicle is in a specific state (e.g., parked or in motion); - The authorization status of the diagnostic equipment (e.g., whether it is an original equipment manufacturer (OEM) device); - Does the current diagnostic device have permission to send diagnostic requests? - Does the vehicle meet specific geographic location parameters (e.g., according to some embodiments of the invention, establishing protected diagnostic sessions outside of official service stations is prohibited. Like many other criteria, this invention proposes implementing this criterion through routing rules stored in a storage device and accessible to the proposed SGW system)? - Whether the vehicle faces information security threats (e.g., based on detected attempts to brute-force high-privilege session keys, detected vehicle time spoofing (NTP, GNSS, etc.), detected CAN bus spoofing (such as attempts to open doors or disable anti-theft devices, etc.)). Depending on the implementation, security threat data may also include: whether there are attempts to brute-force keys or suspicious messages on the CAN bus; the number of diagnostic requests per unit time exceeds a preset threshold; the time interval between diagnostic requests is less than a preset threshold; the time interval between a diagnostic request and a response is less than a preset threshold; diagnostic requests after a sudden change in vehicle location (not achievable based on vehicle speed indicators); diagnostics performed by a diagnostic device connected via OBD-II when the vehicle is off; diagnostic requests issued by third-party applications through a session with the vehicle's infotainment system; diagnostic requests issued after an accident. - Accident sensor trigger information. For example, for electric vehicles, it is particularly important to incorporate and verify accident sensor trigger information into routing rules to prevent the continued use of the vehicle after an accident without diagnosing the power module. Even minor damage to the power module can lead to uncontrollable overheating, fire, or explosion risks during vehicle operation.

[0096] Those skilled in the art will understand that the routing rules accessible to the SGW system proposed in this invention, as an exemplary description of this invention, may contain other additional information not directly mentioned in this specification.

[0097] According to the present invention, the SGW system acquires information from other vehicle components or external interfaces (e.g., GNSS, Ethernet ports, NFC readers, etc.) and checks whether the collected data conforms to existing routing rules. Furthermore, the function of updating routing rules is also implemented. Specifically, according to some embodiments of the present invention, routing rules can be rewritten upon receiving a corresponding command, such as during OTA updates, during diagnostic updates, or as a result of receiving a corresponding remote command from an OEM server.

[0098] According to some embodiments of the present invention, the organization of routing rules can be based on several sub-parts, which contain information directly related to the diagnostic request, as well as additional information obtained from different sources. For example, in the sub-part describing the diagnostic request, according to some embodiments of the present invention, records such as the diagnostic device address, ECU number, and diagnostic service number are included. In the sub-part containing additional information obtained from different sources, according to some embodiments of the present invention, records such as the vehicle state attribute "vehicleState", the security state attribute "securityState", and location are included. Those skilled in the art will understand that in practical applications, various implementations can adopt corresponding different routing rule modifications according to security strategies and factors that need to be considered in specific embodiments of the present invention. The records used can have multiple value lists, and these values ​​may also come from the analysis results of information on other vehicle components and systems. For example, according to some embodiments of the present invention, the attribute "vehicleState" can be set to values ​​such as "parking", "update", and "drive". Such a value list can realize the routing and control of diagnostic requests, for example, preventing update operations from being performed while driving. According to one embodiment of the present invention, the attribute "securityState" can be set to "secure" (no signs of deception, geolocation change or other security threats) and "insecure" (one or more events indicating the presence of a security threat have been recorded according to the logic adopted by this embodiment).

[0099] The non-restrictive examples of the composition of routing rule fields, their possible values, and their uses are shown in Tables 1 and 2 below, and examples will be used later to illustrate how to parse and match data according to routing rules.

[0100] Diagnostic request routing

[0101] According to one embodiment of the present invention, the SGW system includes a functional module whose main function is to process and route requests between external diagnostic devices and vehicle ECUs based on routing rules.

[0102] Next, the request routing process will be described using a specific case where the diagnostic request follows the UDS format and the vehicle is a car, according to the present invention. However, those skilled in the art will understand that the present invention is not limited to the given example. As mentioned above, the present invention can be combined with other data exchange standards and protocols and implemented in various other types of vehicles to ensure security and prevent unauthorized operation of the vehicle and its components.

[0103] According to one embodiment of the present invention, the SGW system includes a diagnostic control module that is capable of processing and routing UDS messages between at least one diagnostic device and at least one ECU (in the case of self-diagnosis, the SGW system module acts as the ECU).

[0104] To ensure secure data exchange during protected UDS sessions with the ECU, diagnostic request routing rules need to be configured in the diagnostic control module. According to the described implementation, a timeout value for the protected diagnostic session (which terminates the diagnostic session if exceeded) and a timeout value for waiting for an ECU response are also set (e.g., defined in a loaded configuration file). Several different scenarios may then occur, as described below, with their processing algorithms summarized as follows. Figure 6 As shown.

[0105] Processing incoming UDS requests from diagnostic devices (in) Figure 6 In the following description, the diagnostic device is also referred to as the "client". Tester (or "Tester")

[0106] Step 601: After receiving the request from the client Tester in step 600, the diagnostic control module processes the request and determines its parameters (e.g., the ECU address to which the request needs to be routed).

[0107] Step 602: The diagnostic control module checks if there is a corresponding routing rule for the request. If a rule is found, proceed to the next step. Otherwise, reject the request and report an error.

[0108] Step 603: The diagnostic control module determines the status of the ECU and checks it against the timeout value.

[0109] If a request has been routed to the ECU but no expected response has been received within the set timeout period, the ECU is in a "Busy" state and should reject the request and report an error. Otherwise, proceed to step 604.

[0110] Step 604: The diagnostic control module determines whether a non-default session has been enabled with the target ECU. A non-default session refers to any session level other than the default session (0x01). If a non-default session has been enabled with the target ECU, proceed to the next step. Otherwise, proceed to step 606.

[0111] Step 605: The diagnostic control module determines whether the non-default session was opened by the client originating from the current request. If yes, proceed to the next step. Otherwise, reject the request and report an error.

[0112] Step 606: The diagnostic control module executes request routing and saves its parameters 60. Saving the parameters is for processing the UDS response from the ECU.

[0113] Step 607: If a response from the ECU is expected to be received for the request, the diagnostic control module saves a record 61 with a status of "Busy" for the ECU.

[0114] Step 608: If a response from the ECU is expected, the diagnostic control module starts a timer to wait for the ECU's response.

[0115] Those skilled in the art will understand that steps 602-606 involve in part or all of obtaining information for applying routing rules, which may come from different sources.

[0116] Processing incoming UDS responses from the ECU

[0117] Step 611: After receiving the response from the ECU in step 610, the diagnostic control module checks whether a request has been sent to the ECU before, based on the previously saved parameter 60. If yes, proceed to the next step. Otherwise, ignore the UDS message.

[0118] Step 612: The diagnostic control module removes the "Busy" status from the ECU.

[0119] Step 613: The diagnostic control module checks whether the received message is a positive UDS response to the request to open a non-default session. If yes, proceed to the next step. Otherwise, proceed to step 615 (response routing).

[0120] Step 614: The diagnostic control module saves the non-default session parameter 62 with the ECU and starts a timer with a duration equal to the session timeout value. The timeout refers to the maximum time interval during which the ECU should receive a request from the diagnostic device. (See Clearing the non-default session identifier with the ECU in the diagnostic control module).

[0121] Step 615: The diagnostic control module routes the response to the client Tester.

[0122] Clear the non-default session identifier for this ECU in the diagnostic control module.

[0123] Step 621: If the ECU does not receive any request within the set timeout period in step 620, the diagnostic control module deletes the non-default session parameter record for that ECU.

[0124] Step 622: The diagnostic control module sends a request to the ECU to switch to the default session.

[0125] Clear the Busy state of the ECU in the diagnostic control module.

[0126] Step 631: If no response is received from the ECU within the timeout period set in step 630, the diagnostic control module deletes the "Busy" status record 61 of the ECU.

[0127] Therefore, we can summarize the scenarios in which requests may be rejected in the following steps:

[0128] Step 605: A UDS request is received pointing to an ECU, but that ECU has already established a non-default session with another client (the request source). Handling: Reject the request and send an error message to the client Tester.

[0129] Step 611: A UDS response is received from the ECU, but this response corresponds to a request unknown to the diagnostic control module. Handling method: Ignore the UDS response.

[0130] Step 603: A UDS request is received pointing to an ECU in Busy state. Handling: Reject the request and send an error message to the client Tester.

[0131] To illustrate this more clearly, the following will combine... Figure 7A and Figure 7B The scenario shown is illustrated, and the diagram illustrates the interaction between the diagnostic equipment, the SGW system, and the ECU.

[0132] Those skilled in the art will understand that, according to some implementations, the first step in interacting with a diagnostic device is to verify its authenticity. It should also be noted that a significant advantage of the data exchange and diagnostic request and response routing method proposed in this invention is that access level control is centralized in the proposed SGW system. The SGW system holds information about which unit and which device are interacting within which session framework, and does not transmit this information elsewhere.

[0133] Example 1: Based on Figure 7A The illustrated operation flow is an example of a diagnostic session control and routing scenario.

[0134] Step 1: A diagnostic request from diagnostic device 720 to switch diagnostic sessions for ECU 750 arrives at SGW system 740.

[0135] Step 2: The SGW system 740 checks whether routing rules exist and whether the conditions set in the rules are met, such as conditions related to vehicle and ECU status: the current status of the vehicle (whether the vehicle is parked, driving, etc.); the current status of the ECU (whether the ECU is busy processing diagnostic requests); the diagnostic session status with the ECU (default or non-default), etc.

[0136] Step 3: If the verification is successful, the SGW system 740 will route the diagnostic request to the ECU 750.

[0137] Step 4: ECU 750 checks the possibility of switching to the requested diagnostic session.

[0138] Step 5: If the check passes, the ECU 750 switches to the requested diagnostic session and sends the response to the SGW system 740.

[0139] Step 6: The SGW system 740 records in its status that the ECU 750 has switched to the requested non-default session, but the security level has not yet been upgraded.

[0140] Step 7: The SGW system 740 transmits the successful response from the ECU 750 to the diagnostic equipment.

[0141] Step 8: The diagnostic device sends a request to the SGW system 740, requesting a change in the access level of the ECU 750 based on the established diagnostic session. The secure access process is initiated.

[0142] Step 9: The SGW system 740 performs a check on the configured routing rules and external status to determine whether the access level change request can be forwarded.

[0143] Step 10: If the check passes, the SGW system 740 will forward the access level change request to the ECU 750.

[0144] Step 11: ECU 750 generates a seed value based on the secure access procedure.

[0145] Step 12: ECU 750 transmits the seed value to SGW system 740, which saves it.

[0146] Step 13: The SGW system 740 uses the ECU's current diagnostic session key (which was previously generated; see the "Replacing the ECU Factory Diagnostic Session Key" section) to perform a conversion calculation on the seed value.

[0147] Step 14: The SGW system 740 transmits the seed value to the diagnostic device 720.

[0148] Step 15: The diagnostic device 720 uses the factory diagnostic session key of the ECU 750 to convert and calculate the seed value.

[0149] Step 16: The diagnostic device 720 sends the conversion results to the SGW system 740.

[0150] Step 17: The SGW system 740 replaces the conversion result received from the diagnostic device 720 with the conversion result of the seed value calculated using the current diagnostic session key of the ECU 750 (see step 13).

[0151] Step 18: The SGW system sends the conversion result of the seed value (Step 13) to ECU 750.

[0152] Step 19: The ECU 750 verifies the converted seed value using the current diagnostic key. If the verification is successful, it switches to the requested access level (security level) for the current non-default diagnostic session.

[0153] Step 20: ECU 750 sends an affirmative response to the received diagnostic request to SGW system 740.

[0154] Step 21: The SGW system 740 generates a record of the status of the ECU 750, indicating that the ECU 750 is in a diagnostic session with the required safety level.

[0155] Step 22: The SGW system 740 will route a positive response to the diagnostic device 720.

[0156] Example 2: Attempting to bypass security mechanisms to diagnose the ECU (e.g.) Figure 7B (As shown).

[0157] Step 1: The diagnostic request from diagnostic device 721 to switch the diagnostic session of ECU 750 is sent directly to the ECU (bypassing SGW system 740).

[0158] Step 2: ECU 750 checks the possibility of switching to the requested diagnostic session.

[0159] Step 3: If the check passes, the ECU 750 switches to the requested diagnostic session and sends a response to the diagnostic device.

[0160] Step 4: The diagnostic device sends a request to ECU 750 to elevate its access level based on the established diagnostic session. The secure access process is initiated.

[0161] Step 5: ECU 750 generates a seed value according to the secure access procedure.

[0162] Step 6: The ECU 750 sends the seed value to the diagnostic device.

[0163] Step 7: Diagnostic device 721 uses the same factory key as ECU 750 or a leaked key to convert and calculate the seed value.

[0164] Step 8: The diagnostic device 721 sends the conversion results to the ECU 750.

[0165] Step 9: ECU 750 uses the current diagnostic key (generated during the pre-production preparation phase and unique to this unit) to verify the converted seed value and rejects the request to upgrade the corresponding security level.

[0166] Step 10: ECU 750 sends a negative response, indicating that it cannot switch to the requested security level due to a diagnostic device authentication error (according to the UDS protocol).

[0167] If the SGW system confirms that the diagnostic device is genuine and the diagnostic device sends a request to the ECU to switch diagnostic sessions (i.e., perform a secure access procedure), then according to the present invention, the diagnostic session control mechanism is activated at this time, and the SGW system uses the previously generated diagnostic session key (generated when a request to generate a key for all ECUs is received) to perform a conversion calculation on the seed value.

[0168] The following is through Figures 8 to 14 The examples shown illustrate specific scenarios in which the present invention works.

[0169] Table 1 provides the following information: Figures 8-11 The example shown illustrates the routing rules used, and the values ​​included in the rules are explained. As explicitly shown in Table 1, the routing rules contain fields describing specific information in each request (this information may vary from request to request), and fields describing the information that the SGW unit obtains from different sources at a given time.

[0170] Table 1. An example structure of routing rules according to one embodiment of the present invention.

[0171]

[0172] 1 TIER1 (Tier 1 Supplier) – Manufacturers that supply OEMs with finished components (especially ECUs) needed to manufacture vehicles.

[0173] Figure 8 An example is shown where the diagnostic control module 830 of the SGW system processes request з2 from a remote diagnostic device 840 (reading the software version in preparation for an update) and request з1 from a local diagnostic device 820, and routes these diagnostic requests to the requested ECU#1 850. In this case, the data evaluated according to the routing rules (Table 1) is shown in Table 2 below.

[0174] Examples of conditions that trigger this scenario include: a remote diagnostic device 840 is connected via an LTE modem, and a local diagnostic device 820 is connected via Ethernet #2 (e.g., a diagnostic application on the IVI). The vehicle is in a "parking" state, parked in a home parking lot, with no security events (no suspected attack attempts), ECU #1 850 is in a "default" session, and no diagnostic device requests a non-default session. The vehicle owner launches an application on the IVI to read calibration parameters. The SGW system's diagnostic control module 830 processes request #2, and based on routing rules, all criteria are met, and the request is routed to the requested ECU #1 850.

[0175] Table 2. Targeting Figure 8 Example data

[0176]

[0177] Figure 9 An example is shown where the diagnostic control module 930 of the SGW system processes request з4 from a remote diagnostic device 940 and request з3 from a local diagnostic device 920. Diagnostic request з3 is blocked because an ExtendedSession has been established with the remote diagnostic device 940. In this case, the data evaluated according to the routing rules (Table 1) for this scenario is shown in Table 3 below.

[0178] The above scenario may occur under the following conditions: Remote diagnostic device 940 is connected via an LTE modem, and local diagnostic device 920 is connected via Ethernet #2 (e.g., a diagnostic application on the IVI). The vehicle is in "parking" mode, parked in a home parking lot, with no security incidents (no suspected attack attempts), and ECU #1 is in an Extended session initiated by remote diagnostic device 940. The vehicle owner launches an application on the IVI to read the unit's calibration parameters.

[0179] Table 3. Targeting Figure 9 Example data

[0180]

[0181] Figure 10An example is shown where the diagnostic control module 1030 of the SGW system processes Extended Session requests (з6) from remote diagnostic device 1040 for ECU#2 1051 and ECU#3 1052, and a request (з5) from the Default Session of local diagnostic device 1020 for ECU#1 1050. Requests to ECU#2 and ECU#3 are routed according to routing rules for these units, which should be correctly configured in the SGW system beforehand and will not be elaborated here. The existing routing rules (Table 1) are compared with the data collected for this scenario (data for ECU#1 1050 is shown in Table 4 below). In the example shown, a diagnostic device 1040 has already established a diagnostic session with the unit pointed to by the target field, and this diagnostic device can also communicate simultaneously with other units ECU#2 1051 and ECU#3 1052.

[0182] Table 4. Targeting Figure 10 Example data

[0183]

[0184] Figure 11 An example is shown where the SGW system's diagnostic control module 1130 blocks a request from the local diagnostic device to ECU#1 1150 because the vehicle is detected to be currently off and there is no active user. According to the routing rules used in this implementation (Table 1), in this case, the diagnostic request is blocked (temporarily not routed to the ECU). Figure 11 As shown, in order to obtain routing rule information, the diagnostic control module 1130 queries the routing rule and vehicle and component information module 1140 (according to some embodiments of the present invention, routing can also be based on information provided by other modules, which provide additional information to the SGW unit). In the specific case where the vehicle is an automobile, the on-board diagnostic system II OBD-II is inaccessible in the described scenario. In this case, the data evaluated according to the routing rules (Table 1) of this scenario is shown in Table 5 below.

[0185] Table 5. Regarding Figure 11 Example data

[0186]

[0187] Table 6 below gives Figures 12-14 The example shown illustrates the routing rules used, and explains the possible values ​​included in the rules.

[0188] Table 6. An example structure of routing rules according to one embodiment of the present invention.

[0189]

[0190] Figure 12 Another example is shown where the SGW system's diagnostic control module 1230 blocks requests from the local diagnostic device 1220 to ECU#1 1250. In this example, the vehicle is powered on, and someone is attempting to switch ECU#1 to a Programming session for reprogramming (software replacement). However, the current user lacks the necessary permissions, and the vehicle is not at an official service center, as reflected in the existing data (as shown in Table 7 below). Therefore, according to the security strategy employed in this embodiment of the invention (implemented through the routing rules shown in Table 6 above), these diagnostic requests must be blocked.

[0191] Table 7. Targeting Figure 12 Example data

[0192]

[0193] Figure 13 Another example is shown where the SGW system's diagnostic control module 1330 blocks requests from the local diagnostic device 1320 to ECU#1 1350. Based on geolocation data, the vehicle is located at a service center, but in this example, the local diagnostic device 1320 made multiple authorization attempts to switch to the Programming Session with ECU#1 1350, which is reflected in the existing data for this scenario (see Table 8 below). According to the security policy (implemented via the routing rules shown in Table 6 above), this situation is considered a vehicle security threat, and all subsequent diagnostic requests from the local diagnostic device 1320 are rejected.

[0194] Table 8. Targeting Figure 13 Example data

[0195]

[0196] Figure 14An example is shown where the SGW system's diagnostic control module 1430 rejects a request from the IVI diagnostic device 1420 (an in-vehicle infotainment system diagnostic tool, i.e., dedicated software or device for managing the vehicle's multimedia and infotainment systems, and capable of sending diagnostic requests) to switch ECU#1 1450 to a Programming Session. The reason is that the IVI or its internal application sending the request was not authenticated, and the device or application authentication failure resulted in a security event, causing the system state to change to securityState=ON (reflected in the existing data shown in Table 9 below). According to the security policy applied in this implementation (specifically implemented through the routing rules shown in Table 6 above), the diagnostic request should be rejected in this case.

[0197] Table 9. Targeting Figure 14 Example data

[0198]

[0199] Those skilled in the art will understand that Figures 8-14 The examples shown are only a part of many specific scenarios that may arise depending on different security policy examples and can be implemented using the routing rules proposed in this invention.

[0200] In summary, as described above, according to the present invention, vehicle data exchange is achieved by utilizing pre-established control and routing mechanisms to process diagnostic requests and their responses. According to the present invention, the most general operational flow for data exchange between the vehicle and the source of the diagnostic request is as follows: Figure 15 As shown: First, step 1510 is performed to generate a unique diagnostic session key for each ECU in the vehicle that has a factory-installed diagnostic session key, and then replaces the ECU's factory-installed diagnostic session key with the generated key. Next, step 1520 is performed to set the routing rules for diagnostic requests and responses. After establishing the diagnostic request and response control and routing mechanism, when a diagnostic request 1530 is received, the unique key carried in the request is first verified 1540. Only if the verification is successful is the request routed 1560 based on vehicle and component information and the set routing rules. When a diagnostic request response 1550 is received (after establishing the control and routing mechanism through steps 1510-1520), the response is also routed according to the set routing rules and vehicle and component information.

[0201] Figure 16 An example of a vehicle 110 in which at least a portion of the invention is implemented is shown.

[0202] Figure 16An example of an in-vehicle network architecture 20 for vehicle 110 is shown, through which various systems and methods or parts thereof described in this document can be implemented. The examples presented are not limited to any particular implementation herein.

[0203] Vehicle (TS) 110 also refers to a technical device used for moving and / or transporting people, goods or equipment thereon. Examples of vehicles 110 include at least passenger cars, trucks, vans, minivans, off-road vehicles, buses, trolleybuses, motorcycles, scooters, electric bicycles, boats, private jet skis and aircraft, as well as electric vehicles and autonomous vehicles.

[0204] like Figure 16 As shown, the in-vehicle network architecture 20 includes a processor 21, a memory 22, one or more electronic control units (ECUs) 160 (hereinafter also referred to as ECU 160), an in-vehicle gateway 30 (in one specific embodiment of the present invention, a security gateway SGW 120), and various hardware components, including at least sensors 40, a driver assistance system 50, and a multimedia system 60 (in one specific embodiment of the present invention, an IVI system 180). The in-vehicle network architecture 20 and / or its constituent units can be implemented either in hardware or through a combination of hardware and software, for example, as an in-vehicle computer or controller.

[0205] Processor 21 is responsible for processing signals and performing general computational and arithmetic functions. The signals processed by processor 21 may include digital signals, computer instructions, processor instructions, messages, bits, bit streams, and other computational objects that can be received, transmitted, and / or detected.

[0206] Memory 22 can be any storage device used to store data and / or computer programs executed by processor 21. Memory 22 may include volatile memory and / or non-volatile memory. Non-volatile memory may include, for example, ROM (Read-Only Memory), PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), and EEPROM (Electrically Erasable Programmable Read-Only Memory). Volatile memory may include, for example, RAM (Random Access Memory), Synchronous RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), and / or Direct Connected Bus RAM (DRRAM).

[0207] The ECU 160 is a device responsible for controlling, regulating, and altering the operation of an automotive electronic system. Modern vehicles contain dozens of ECUs, responsible for functions in various systems, from fuel injectors to windshield wiper modes. Depending on the implementation, the ECU 160 may contain one or more processors, each with one or more cores, memory (e.g., read-only memory (ROM) and / or random access memory (RAM)), buses for data transmission and communication, and interfaces for the ECU 160 to receive and send data. An example of an ECU 160 is the engine electronic control unit, which is the main electronic module for the powertrain centralized control system and / or vehicle assistance systems / components. ECUs 160 interact with each other and with other components of the vehicle 110 via data buses (e.g., the CAN protocol bus) and Ethernet network interfaces. Examples of other data buses include LIN (Local Interconnect Network) or FlexRay. Data transmitted via the CAN bus is called a CAN message. Figure 16 Examples of ECU 160 not shown include anti-lock braking systems, electronic stability control systems, air conditioning control systems, and door control units. It should be noted that the examples of ECU 160 described above are not exhaustive and may include other ECUs known in the art.

[0208] The vehicle gateway 30 (one specific implementation of which is the security gateway SGW 120) is a hardware and software complex designed to ensure interaction between the various hardware components of the vehicle network architecture 20 (including with the ECU 160) and with external sources (e.g., other vehicles, cloud servers, diagnostic equipment, etc.). In addition to Figure 16 In addition to the layout shown, the vehicle gateway 30 can also be implemented in one or more ECUs 160 of the vehicle 110. The vehicle gateway 30 can be implemented as a network device, such as a hub or switch. In one embodiment, the vehicle gateway 30 is a security gateway managed by a secure operating system (such as Kaspersky OS).

[0209] In addition to routing CAN messages, the vehicle gateway 30 can also utilize a built-in modem to send / receive electronic signals in the vehicle 110's network via wired or wireless means using various protocols, and communicate with external sources through cloud infrastructure. These protocols can include wireless systems using radio frequency (RF) communication (e.g., IEEE 802.11 (Wi-Fi), IEEE 802.15.1 (Bluetooth®)), near field communication (NFC) systems (e.g., ISO 13157), local area networks (LAN), wireless wide area networks (WWAN), mobile wireless high-speed data transmission (LTE), and / or peer-to-peer systems.

[0210] Sensor 40 is used to provide information about numerous parameters of vehicle 110. Sensor 40 can also provide this parameter information to driver assistance system 50, multimedia system 60, and vehicle gateway 30. Sensor 40 may include a variety of sensors, specifically including LiDAR systems, GPS sensors, inertial measurement units (IMUs), radar and / or cameras, odometers, or image capture devices (e.g., scanners). The sensor examples given above are not exhaustive, and the list of sensors 40 may vary according to implementations of the invention.

[0211] The driver assistance system 50 is designed to assist the driver in operating the vehicle 110. The driver assistance system 50 may be an advanced driver-assistance system (ADAS). The driver assistance system 50 interacts with sensors 40, acquiring data from them via a CAN bus. The driver assistance system 50 may include and / or integrate various ECUs, specifically including parking radar (also known as reversing radar or parking assist system), an engine preheater, an anti-lock braking system (ABS), and a rearview camera system. The driver assistance system 50 may also interact with the multimedia system 60, for example, by sending data about the engine temperature of the vehicle 110.

[0212] The multimedia system 60 (one specific implementation of which is an IVI system 180) is at least used to inform the driver of the status of the vehicle 110 and information about the surrounding environment, and to receive instructions from the driver, such as instructions to confirm software updates. The multimedia system 60 can interact with the sensor 40 via Ethernet. The multimedia system 60 can interact with the sensor 40 to display the status of the vehicle 110, such as displaying the current tire pressure of the vehicle 110.

[0213] The multimedia system 60 can be implemented in the form of hardware and software in the vehicle 110, such as an infotainment system.

[0214] Finally, it should be noted that the information provided in this specification is merely illustrative and is not intended to limit the scope of the invention as defined by the claims. Those skilled in the art will understand that in developing any actual embodiment of the invention, numerous decisions need to be made for specific embodiments to achieve specific objectives, and these specific objectives will vary from embodiment to embodiment. It should be understood that such development work can be complex and time-consuming; however, it will remain a routine engineering task for those with conventional skills in the art, aided by the disclosure of this invention.

[0215] The examples of specific parameters and states to be considered in the process of vehicle diagnostic request control and routing listed in this specification are intended to illustrate the invention only and are in no way intended to limit its application under the full scope of the appended claims.

Claims

1. A method for exchanging data between a vehicle and a diagnostic request source, the method comprising: Generate a unique diagnostic session key for each electronic control unit (ECU) in the vehicle that has a factory diagnostic session key, and replace the factory diagnostic session key of the ECU with the generated unique diagnostic session key; Configure routing rules for diagnostic requests and responses; When a diagnostic request is received, the unique diagnostic session key is first verified for the ECU to which the diagnostic request is directed. If the verification is successful, the received diagnostic request is routed according to the information of the vehicle and its components and the routing rules. When a response to the diagnostic request is received, the response is also routed based on the information about the vehicle and its components, as well as the routing rules.

2. The method according to claim 1, wherein, The routing rules shall include at least the following information: Does a diagnostic session exist with the requested ECU? Do you currently have the permission and / or authorization to send diagnostic requests? For the diagnostic request source, does it have the authorization to send a diagnostic request to the requested ECU? Are there any restrictions on routing diagnostic requests and their responses based on identifiers that indicate vehicle information security threats? Are there any restrictions on routing diagnostic requests and responses based on vehicle location? 3. The method according to claim 1, wherein, The information about the vehicle and its components should take into account at least the following factors: whether there are active users with specific roles in the vehicle, whether the vehicle is drivable, whether the vehicle is in motion, and whether there are identifiers indicating vehicle information security threats.

4. The method according to claim 2 or 3, wherein, The identifier indicating a vehicle information security threat is information indicating at least one of the following: The number of diagnostic requests per unit time exceeds a preset threshold; The time interval between diagnostic requests is less than a preset threshold; The time interval between the diagnostic request and the response is less than a preset threshold; Diagnostic requests following a drastic change in location; A diagnostic request is sent by a diagnostic device connected to OBD-II when the vehicle is turned off; Diagnostic requests issued by a third-party application through a conversation with the vehicle's infotainment system; A diagnostic request issued after the accident.

5. The method according to claim 1, wherein, The routing rules are based on the status information of the vehicle and its components.

6. The method according to claim 1, wherein, If the received diagnostic request or response does not have the corresponding routing rules set, then the received diagnostic request or response is rejected.

7. The method according to claim 1, further comprising: The routing rules are updated upon receiving the corresponding instructions.

8. The method according to claim 1, wherein, The unique diagnostic session key generated for each ECU of the vehicle is encrypted and backed up using a key derivation method, so that it can be restored when needed.

9. A system for exchanging data between a vehicle and a diagnostic request source, the system comprising at least one processor and at least one storage device, and configured to: The vehicle's onboard network is connected to the vehicle. Generate a unique diagnostic session key for each electronic control unit (ECU) of the vehicle, and store the unique diagnostic session key in encrypted form; Replace the existing diagnostic session key of the electronic control unit with the generated unique diagnostic session key; Based on the set routing rules and information about the vehicle and its components, receive and route diagnostic requests and their responses; Store the configured routing rules.

10. The system according to claim 9, wherein, The routing rules shall include at least the following information: Does a diagnostic session exist with the requested ECU? Do you currently have the permission and / or authorization to send diagnostic requests? For the diagnostic request source, does it have the authorization to send a diagnostic request to the requested ECU? Are there any restrictions on routing diagnostic requests and their responses based on identifiers that indicate vehicle information security threats? Are there any restrictions on routing diagnostic requests and responses based on vehicle location? 11. The system according to claim 9, wherein, The information about the vehicle and its components should take into account at least the following factors: whether there are active users with specific roles in the vehicle, whether the vehicle is drivable, whether the vehicle is in motion, and whether there are identifiers indicating vehicle information security threats.

12. The system according to claim 10 or 11, wherein, The identifier indicating a vehicle information security threat is information indicating at least one of the following: The number of diagnostic requests per unit time exceeds a preset threshold; The time interval between diagnostic requests is less than a preset threshold; The time interval between the diagnostic request and the response is less than a preset threshold; Diagnostic requests following a drastic change in location; A diagnostic request is sent by a diagnostic device connected to OBD-II when the vehicle is turned off; Diagnostic requests issued by a third-party application through a conversation with the vehicle's infotainment system; A diagnostic request issued after the accident.

13. The system according to claim 9, wherein, The routing rules are based on the status information of the vehicle and its components.

14. The system according to claim 9, wherein, The system is configured to reject a received diagnostic request or response if no corresponding routing rule is set.

15. The system according to claim 9, wherein, The system is also configured to update the routing rules upon receiving a corresponding instruction.

16. The system according to claim 9, wherein, The system is configured to: back up the unique diagnostic session key generated for each ECU of the vehicle, and request and obtain the backup of the diagnostic session key via a network.

17. The system according to claim 16, wherein, The system is also configured to perform the backup in encrypted form via key derivation so that it can be restored when needed.

Images