A method, system, device, and medium for authenticating access to an automotive OBD port.
By implementing TLS two-way authentication and whitelist verification at the vehicle's OBD port and negotiating an encrypted channel keep-alive mechanism, the security threats to vehicle diagnostic services are resolved, ensuring the legitimacy of diagnostic equipment and the security of data.
Patent Information
- Application Number
- CN202411049686.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-01
- Publication Date
- 2025-10-31
- Estimated Expiration
- 2044-08-01
AI Technical Summary
In existing technologies, the UDS protocol of vehicle diagnostic services via the OBD port is subject to security threats, which may lead to malicious modification or black market activities, necessitating improvements in the security of diagnostic services.
Connect the diagnostic device via the DOIP port to perform TLS two-way authentication, whitelist verification, negotiate a symmetric algorithm for encrypted channel keep-alive, and design keep-alive strategies to ensure link authenticity and reliability.
It implements two-way authentication based on the TLS protocol to ensure the legitimacy of diagnostic equipment, prevent unauthorized access, protect vehicle data security, and allow legitimate devices to read regulatory data.
Smart Images

Figure CN119094160B_ABST
Abstract
Description
Technical Field
[0001] This disclosure belongs to the field of automotive communication technology, and in particular relates to an authentication method for automotive OBD port access. Background Technology
[0002] Generally, vehicle diagnostics are performed by connecting a diagnostic device (such as a diagnostic tool) to the vehicle's OBD port using the UDS protocol. The UDS protocol includes a set of services that allow for various operations such as reading, writing, and executing data on vehicle components (ECUs), and grants extremely high privileges. Therefore, improper use of diagnostic services (such as abuse) can lead to malicious modifications to any vehicle or the creation of black market activities, causing losses to car owners and automakers.
[0003] The main security threats in various scenarios of diagnostic services are as follows:
[0004]
[0005] To improve the security of diagnostic services, the aforementioned risks need to be eliminated to achieve the following state:
[0006]
[0007] Therefore, it is necessary to provide a new method, system, device, and medium for automotive OBD port access authentication to solve the above-mentioned technical problems. Summary of the Invention
[0008] The purpose of this disclosure is to provide a method, system, device, and medium for authenticating access to an automotive OBD port in order to solve the above-mentioned problems.
[0009] This disclosure achieves the above objectives through the following technical solutions:
[0010] A method for authenticating access to an automotive OBD port includes the following steps:
[0011] Connect the diagnostic device via the DOIP port. If the connection fails, perform TLS two-way authentication via the authentication port. After successful TLS two-way authentication, open the DOIP port to connect the diagnostic device, allow UDS services, and keep it alive.
[0012] As a further optimization of this disclosure, the OBD port integrates a CAN interface and an ETH interface.
[0013] As a further optimization of this disclosure, both the DOIP port and the authentication port are connected to the diagnostic device through the ETH interface.
[0014] As a further optimization of this disclosure, before connecting the diagnostic device through the DOIP port, a whitelist is constructed to determine whether the diagnostic device belongs to the whitelist. If so, the connection is made through the CAN interface.
[0015] As a further optimization of this disclosure, the whitelist diagnostic device does not require device access authentication and is allowed to read regulatory data.
[0016] As a further optimization of this disclosure, the prerequisites for TLS two-way authentication via the authentication port include:
[0017] The diagnostic device has a pre-installed device certificate and a root certificate for verifying the in-vehicle access authentication controller certificate; the in-vehicle access authentication controller has a pre-installed device certificate and a root certificate for verifying the diagnostic device certificate.
[0018] As a further optimization of this disclosure, keep-alive includes:
[0019] A negotiated symmetric algorithm is used to encrypt the channel;
[0020] The client periodically sends keep-alive parameters to the server via an encrypted channel;
[0021] The server receives keep-alive parameters. If five keep-alive parameters are lost consecutively, the connection is disconnected and the DOIP port is closed.
[0022] A vehicle OBD port access authentication system, comprising:
[0023] Try connecting the module to connect the diagnostic device via the DOIP port;
[0024] The two-way authentication connection module is used to perform TLS two-way authentication through the authentication port after the connection to the diagnostic device fails through the DOIP port. After the TLS two-way authentication is successful, the DOIP port is opened to connect to the diagnostic device, allowing UDS services and keeping it alive.
[0025] An electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;
[0026] Memory, used to store computer programs;
[0027] The processor, when executing programs stored in memory, implements the vehicle OBD port access authentication method.
[0028] A computer-readable storage medium storing a computer program that, when executed by a processor, implements a method for authenticating access to an OBD port in a vehicle.
[0029] The beneficial effects of this disclosure are as follows:
[0030] This disclosure uses the TLS protocol to perform two-way authentication between diagnostic devices and vehicles. After successful authentication, a keep-alive strategy is designed to ensure the authenticity and reliability of the link. At the same time, a whitelist is designed to allow third-party devices to read regulatory data. Attached Figure Description
[0031] Figure 1 This is a flowchart of the method disclosed herein;
[0032] Figure 2 This is a schematic diagram of the device access authentication framework in this embodiment of the present disclosure;
[0033] Figure 3 This is a schematic diagram of the OBD and diagnostic related ports in this embodiment of the present disclosure;
[0034] Figure 4 This is a flowchart of the access authentication process in this embodiment of the present disclosure;
[0035] Figure 5 This is a system framework diagram of this embodiment of the present disclosure;
[0036] Figure 6 This is a device framework diagram of this embodiment of the present disclosure. Detailed Implementation
[0037] The present application will now be described in further detail with reference to the accompanying drawings. It should be noted that the following specific embodiments are only used to further illustrate the present application and should not be construed as limiting the scope of protection of the present application. Those skilled in the art can make some non-essential improvements and adjustments to the present application based on the above application content.
[0038] like Figure 1 As shown, a method for authenticating access to an OBD port in a car includes the following steps:
[0039] Connect the diagnostic device via the DOIP port. If the connection fails, perform TLS (Transport Layer Security) two-way authentication via the authentication port. After successful TLS two-way authentication, open the DOIP (Diagnostic over Internet Protocol) port to connect the diagnostic device, allowing UDS services and keeping it alive.
[0040] In this embodiment, the method specifically includes:
[0041] Device access authentication framework such as Figure 2 As shown, the OBD and diagnostic-related ports are as follows: Figure 3 As shown;
[0042] Port 30504 (Authentication Port): Used for device authentication;
[0043] Port 13400 (DOIP port): UDS channel for ETH (Ethernet) diagnostic devices;
[0044] CAN port: The UDS channel of a CAN device;
[0045] Main features:
[0046] ETH access authentication: TLS-based two-way authentication is performed on port 30504. After successful authentication, an encryption key is negotiated for keep-alive, and port 13400 is opened at the same time.
[0047] CAN port: Supports switch control and can control function switches via UDS;
[0048] ETH Access Authentication Switch (Controls 13400 Port to Always Open): Supports switch control and enables access authentication function via UDS command;
[0049] OBD whitelist: Allows reading of regulatory data.
[0050] I. The device access authentication process is as follows:
[0051] like Figure 4 As shown, after the diagnostic device is connected to the vehicle's OBD port, it first tries to connect via port 13400 (DOIP port). If that fails, it performs TLS two-way authentication via port 30504 (authentication port).
[0052] Prerequisites:
[0053] The diagnostic equipment comes pre-installed with a device certificate and a root certificate for verifying the in-vehicle access authentication controller certificate;
[0054] The in-vehicle access authentication controller has a pre-installed device certificate and a root certificate for verifying and diagnosing device certificates.
[0055] 1. Two-way authentication: Implementation of certificate authentication process based on TLS standard:
[0056] Certificate: Supports X.509 format
[0057] TLS version: 1.2 and above
[0058] Signature algorithm: ED25519
[0059] TLS cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[0060] 2. After successful two-way authentication, open port 13400 to allow UDS services.
[0061] 3. Keep alive
[0062] a) After successful two-way authentication, negotiate a symmetric algorithm (e.g., AES GCM 128) to encrypt the channel.
[0063] b) The client periodically sends keep-alive parameters to the server via an encrypted channel.
[0064] i. Transmission frequency: Once per second
[0065] ii. Parameters: counter = 0; counter++ (increment by 1 per second);
[0066] iii. Counter byte length: 4 bytes, unsigned integer
[0067] iv. Encryption: Transmitted after encryption using a symmetric algorithm.
[0068] v. The keep-alive message uses a TCP segment with a 4-byte payload containing the Counter value.
[0069] c) The server receives keep-alive parameters. If five parameters are lost consecutively, the connection is disconnected and port 13400 is closed.
[0070] II. Port Switch Control
[0071] The ports primarily related to device access authentication are: port 30504, port 13400, and the CAN port. The on / off states of these ports differ at different stages. To configure and store these settings, a "OBD Secure Access Mode" configuration item is introduced. The relationship between "OBD Secure Access Mode" and each port is as follows:
[0072] 1. Off (Non-secure mode): When the in-vehicle access authentication controller component leaves the factory, "OBD secure access mode" is off, and the status of each port is as follows:
[0073] ETH Access Authentication: Enabled;
[0074] CAN port: On;
[0075] Port 13400: Open.
[0076] 2. Enable (Security Mode): After the vehicle manufacturer completes the installation, the in-vehicle access authentication controller needs to be set to enabled (Security Mode). After enabling, the status of each port is as follows:
[0077] ETH Access Authentication: Enabled;
[0078] CAN port: Off;
[0079] Port 13400: Closed.
[0080] The mapping relationship between "OBD secure access mode" and each port at different stages is shown in the table below:
[0081]
[0082]
[0083] III. Functional Interface
[0084] 1. OBD secure access mode switching (persistent storage) switching command:
[0085]
[0086] response:
[0087]
[0088] 2. Commands for querying and switching the current OBD security access mode:
[0089]
[0090] response:
[0091]
[0092]
[0093] IV. Relevant Needs of Automakers
[0094]
[0095]
[0096] like Figure 5 As shown, embodiments of this disclosure provide an automotive OBD port access authentication system, including:
[0097] Attempt to connect module 11 to connect the diagnostic device via the DOIP port;
[0098] The two-way authentication connection module 12 is used to perform TLS two-way authentication through the authentication port after the connection to the diagnostic device fails through the DOIP port. After the TLS two-way authentication is successful, the DOIP port is opened to connect to the diagnostic device, allowing UDS services and keeping it alive.
[0099] The implementation process of the functions and roles of each module in the above system is detailed in the implementation process of the corresponding steps in the above method, and will not be repeated here.
[0100] For the system embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The system embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.
[0101] In the above embodiments, any number of modules can be combined into one module, or any one module can be split into multiple modules. Alternatively, at least some functionality of one or more modules can be combined with at least some functionality of other modules and implemented in one module. At least one of the modules can be at least partially implemented as hardware circuitry, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a System-on-Chip, a System-on-Substrate, a System-on-Package, an Application-Specific Integrated Circuit (ASIC), or any other reasonable method of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three methods. Alternatively, at least one of the modules can be at least partially implemented as a computer program module that, when run, performs a corresponding function.
[0102] See Figure 6 The electronic device provided in the embodiments of this disclosure includes a processor 1110, a communication interface 1120, a memory 1130 and a communication bus 1140, wherein the processor 1110, the communication interface 1120 and the memory 1130 communicate with each other through the communication bus 1140.
[0103] Memory 1130 is used to store computer programs;
[0104] When the processor 1110 executes the program stored in the memory 1130, it implements the following vehicle OBD port access authentication method.
[0105] The aforementioned communication bus 1140 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus 1140 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, it is represented by only one thick line in the figure, but this does not indicate that there is only one bus or one type of bus.
[0106] The communication interface 1120 is used for communication between the above-mentioned electronic device and other devices.
[0107] The memory 1130 may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1130 may also be at least one storage device located remotely from the aforementioned processor 1110.
[0108] The processor 1110 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0109] Embodiments of this disclosure also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program that, when executed by a processor, implements the vehicle OBD port access authentication method as described above.
[0110] The computer-readable storage medium may be included in the device / apparatus described in the above embodiments; or it may exist independently and not assembled into the device / apparatus. The computer-readable storage medium carries one or more programs that, when executed, implement the vehicle OBD port access authentication method according to embodiments of this disclosure.
[0111] According to embodiments of this disclosure, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
[0112] The embodiments described above are merely examples of several implementations of this disclosure, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent disclosure. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this disclosure, and these modifications and improvements all fall within the protection scope of this disclosure.
Claims
1. A method for authenticating access to an automotive OBD port, characterized in that, Includes the following steps: Connect the diagnostic device via the DOIP port. If the connection fails, perform TLS two-way authentication via the authentication port. After successful TLS two-way authentication, open the DOIP port to connect the diagnostic device, allow UDS services, and keep it alive. The OBD port integrates a CAN interface and an ETH interface. Both the DOIP port and the authentication port are connected to the diagnostic device via the ETH interface; Before connecting the diagnostic device via the DOIP port, a whitelist is built to determine whether the diagnostic device belongs to the whitelist. If so, the connection is made via the CAN interface. The prerequisites for TLS two-way authentication via the authentication port include: The diagnostic equipment comes pre-installed with a device certificate and a root certificate for verifying the in-vehicle access authentication controller certificate; The in-vehicle access authentication controller has a pre-installed device certificate and a root certificate for verifying and diagnosing device certificates; Two-way authentication is implemented based on the certificate authentication process of the TLS standard; After successful two-way authentication, open the DOIP port to allow UDS services. Keeping alive includes: After two-way authentication is successful, a symmetric algorithm is negotiated to encrypt the channel; The client periodically sends keep-alive parameters to the server through an encrypted channel, including: a sending frequency of once per second; parameters of counter = 0, counter++, incrementing by 1 every second; a counter byte length of 4 bytes, an unsigned integer; encryption using a symmetric algorithm before transmission; and keep-alive messages using TCP packets with a payload length of 4 bytes, containing the counter value. The server receives keep-alive parameters. If five parameters are lost consecutively, the connection is closed and the DOIP port is shut down.
2. The automotive OBD port access authentication method according to claim 1, characterized in that, The whitelisted diagnostic devices do not require device access authentication and are allowed to read regulatory data.
3. A vehicle OBD port access authentication system, characterized in that, include: Try connecting the module to connect the diagnostic device via the DOIP port; The two-way authentication connection module is used to perform TLS two-way authentication through the authentication port after the connection to the diagnostic device fails through the DOIP port. After the TLS two-way authentication is successful, the DOIP port is opened to connect to the diagnostic device, allowing UDS services and keeping it alive. The OBD port integrates a CAN interface and an ETH interface. Both the DOIP port and the authentication port are connected to the diagnostic device via the ETH interface; Before connecting the diagnostic device via the DOIP port, a whitelist is built to determine whether the diagnostic device belongs to the whitelist. If so, the connection is made via the CAN interface. The prerequisites for TLS two-way authentication via the authentication port include: The diagnostic equipment comes pre-installed with a device certificate and a root certificate for verifying the in-vehicle access authentication controller certificate; The in-vehicle access authentication controller has a pre-installed device certificate and a root certificate for verifying and diagnosing device certificates; Two-way authentication is implemented based on the certificate authentication process of the TLS standard; After successful two-way authentication, open the DOIP port to allow UDS services. Keeping alive includes: After two-way authentication is successful, a symmetric algorithm is negotiated to encrypt the channel; The client periodically sends keep-alive parameters to the server through an encrypted channel, including: a sending frequency of once per second; parameters of counter = 0, counter++, incrementing by 1 every second; a counter byte length of 4 bytes, an unsigned integer; encryption using a symmetric algorithm before transmission; and keep-alive messages using TCP packets with a payload length of 4 bytes, containing the counter value. The server receives keep-alive parameters. If five parameters are lost consecutively, the connection is disconnected and the DOIP port is closed.
4. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in a memory, implements the vehicle OBD port access authentication method as described in any one of claims 1-2.
5. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the vehicle OBD port access authentication method as described in any one of claims 1-2.
Citation Information
Patent Citations
TLS authentication method, device and system, electronic equipment and readable medium
CN113328980A
Vehicle diagnosis method, vehicle, diagnosis equipment and storage medium
CN117170347A