Intrusion detection method for vehicle-mounted UDS protocol
By setting intrusion detection methods for the on-vehicle UDS protocol, intrusion detection rules are set and ECU configuration rules for each subnet of the in-vehicle CAN bus network, the problem of missing UDS protocol intrusion detection in the on-vehicle CAN bus network is solved, and accurate positioning and detection efficiency of feature attacks are achieved.
Patent Information
- Application Number
- CN202211578502.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-12-06
- Publication Date
- 2025-04-25
- Estimated Expiration
- 2042-12-06
AI Technical Summary
The intrusion detection method of the vehicle-mounted UDS protocol in the prior art has been missing, resulting in insufficient intrusion detection of the vehicle-mounted CAN bus network at the protocol level.
For the on-board UDS protocol, intrusion detection rules are set, including illegal diagnostic request inspection rules, illegal diagnostic response inspection rules, diagnostic request legality inspection rules, violent request authentication inspection rules, DTC active upload inspection rules and malicious continuous reset inspection rules. For each subnet in the CAN bus network in the vehicle, intrusion detection rules are configured for the ECUs in it according to actual needs, and intrusion detection is performed on the requested data in turn during the intrusion detection cycle.
Through the intrusion detection method against the UDS protocol, feature attacks can be accurately positioned, the accuracy and efficiency of intrusion detection can be improved, and the insufficient detection at the protocol level is made up.
Smart Images

Figure CN115941330B_ABST
Abstract
Description
Technical Field
[0001] The invention belongs to the technical field of automobile vehicle-mounted system intrusion detection, and more specifically, relates to an intrusion detection method for a vehicle-mounted UDS protocol. Background Art
[0002] At present, the CAN (Control Area Network) bus, as the communication bus between various ECUs (Electronic Control Units), has become the most widely used bus protocol in automobiles and a research hotspot for domestic and foreign automobile manufacturers. Through CAN messages, various parts of the car can be directly controlled, so CAN bus security detection and defense is the last line of defense for the security of connected cars. In-car intrusion detection is the most important and effective means of protection.
[0003] Nowadays, the basis of network intrusion detection and defense is IDS (intrusion detection system). Only when the attack is detected and the type and method of the attack are determined, can effective defense measures be determined. Although the current key technologies of intrusion detection have their own advantages, especially anomaly detection technology, which has become the mainstream technology of intrusion detection technology, its single development makes the accuracy of detection need to be improved. With the continuous research of technology, intrusion detection technology based on protocol analysis has gradually become one of the main research technologies.
[0004] So far, people have tried different directions for intrusion detection methods of in-vehicle CAN bus networks. For example, Michael Muter first applied information entropy theory to CAN bus anomaly detection and introduced 8 anomaly sensors to comprehensively evaluate in-vehicle bus threats, including detection of frame ID, detection of data load, detection of message frequency, detection of message sequence tampering, etc. Larson proposed a CAN bus intrusion detection method based on the in-vehicle communication protocol standard. It targets the CanOpen protocol, analyzes its protocol specifications, detects malformed messages that violate the protocol, and provides a set of security rules. At the same time, theories such as machine learning and neural networks have also become popular directions for studying in-vehicle CAN bus intrusion detection. Deep neural networks are used to detect automobile information security issues, hidden Markov models are used to detect abnormal changes in automobile speed and engine speed, and time recursive neural networks LSTM are used to perform offline anomaly detection on collected CAN data. Although these methods have helped in-vehicle intrusion detection, there are very few applications of intrusion detection technology based on protocol analysis in CAN bus networks, and there is a lack of methods for the UDS (Unified Diagnostic Services) protocol. Summary of the invention
[0005] The purpose of the present invention is to overcome the shortcomings of the prior art and provide an intrusion detection method for the vehicle-mounted UDS protocol, setting intrusion detection rules for the UDS protocol to ensure the security of upper layer protocol communication.
[0006] In order to achieve the above-mentioned object of the invention, the intrusion detection method for the vehicle-mounted UDS protocol of the present invention comprises the following steps:
[0007] S1: Set intrusion detection rules for the vehicle UDS protocol, including illegal diagnostic request check rules, illegal diagnostic response check rules, diagnostic request legitimacy check rules, violent request authentication check rules, DTC active upload check rules, and malicious continuous reset check rules, among which:
[0008] The illegal diagnostic request check rule presets the SID whitelist according to actual needs, and checks and matches the SID in the request data sent by the diagnostic direction to the ECU with the preset SID whitelist in the rule. If a SID not defined in the whitelist appears, an exception is reported, otherwise the request data is processed normally;
[0009] The illegal diagnosis response check rule presets a response ID whitelist according to actual needs, matches the response ID in the diagnosis request with the preset response ID whitelist in the rule, and reports an exception if an undefined response ID appears, otherwise the request data is processed normally;
[0010] The diagnostic request validity check rules set the requirements for SID, field range number, field position, field format, reference value relationship, and reference value in the diagnostic request data according to actual needs, and check whether a certain field range of the request data meets the requirements. If it does not meet the requirements, an exception is reported, otherwise the request data is processed normally;
[0011] The brute force request authentication check rule sets the number threshold and minimum interval time of permission acquisition requests per unit time length according to actual needs. If the number of permission acquisition requests per unit time length exceeds the number threshold, or the interval time between two permission acquisition requests is less than the minimum interval time, an exception is reported. Otherwise, the request data is processed normally.
[0012] The DTC active upload check rule is that if a diagnostic request is received to enable DTC active upload, an exception will be reported, otherwise the request data will be processed normally;
[0013] Malicious continuous reset check rules set the ECU reset request detection number threshold other than self-reset detection according to actual needs. If the number of ECU reset request detections other than self-reset detection forwarded by the gateway exceeds the threshold, an exception is reported, otherwise the request data is processed normally;
[0014] S2: For each subnet in the in-vehicle CAN bus network, set several intrusion detection rules for the ECU therein according to actual needs. Each rule is identified by the CAN ID of the ECU, and then the intrusion detection rules of all subnets are saved;
[0015] S3: When the diagnostic direction sends request data to the ECU, the request data is cached in the cache area of the subnet to which the ECU belongs. Whenever the intrusion detection cycle arrives, the request data of each subnet is subjected to intrusion detection in turn using the following method: the request data is read from the cache area of the current subnet, and then all intrusion detection rules of the ECU corresponding to the request data are retrieved and read, and the request data is matched and detected using each intrusion detection rule in turn. After all request data of the current subnet are detected, jump to the next subnet until all currently cached request data are detected.
[0016] The present invention is directed to an intrusion detection method for an on-vehicle UDS protocol, and sets intrusion detection rules for the on-vehicle UDS protocol, including illegal diagnosis request inspection rules, illegal diagnosis response inspection rules, diagnosis request legitimacy inspection rules, violent request authentication inspection rules, DTC active upload inspection rules, and malicious continuous reset inspection rules. For each subnet in an in-vehicle CAN bus network, an intrusion detection rule is configured for the ECU therein according to actual needs, and request data sent from the diagnosis direction ECU is cached in a cache area of the subnet to which the ECU belongs. Whenever an intrusion detection cycle arrives, the intrusion detection rules of the subnet are used in turn to perform intrusion detection on the request data.
[0017] The present invention has the following beneficial effects:
[0018] 1) Based on the existing intrusion detection of the vehicle internal CAN network, the present invention considers the security of the upper layer protocol level, proposes a number of detection rules for the UDS protocol, ensures the integrity of the intrusion detection of the vehicle CAN bus network, and makes up for the deficiencies at the protocol level;
[0019] 2) The intrusion detection method for the UDS protocol proposed in the present invention can accurately locate the characteristic attack and make up for the defect that the conventional anomaly detection cannot accurately determine;
[0020] 3) The present invention uses fewer rules to describe unacceptable behaviors, which can improve the speed and efficiency of anomaly detection. BRIEF DESCRIPTION OF THE DRAWINGS
[0021] Figure 1 It is a flowchart of a specific implementation method of the intrusion detection method for the vehicle-mounted UDS protocol of the present invention;
[0022] Figure 2is an example diagram of the process of checking illegal diagnostic requests in this embodiment;
[0023] Figure 3 It is a flowchart for obtaining permissions;
[0024] Figure 4 is an example diagram of the process of brute force request authentication check in this embodiment;
[0025] Figure 5 It is the flowchart uploaded by DTC;
[0026] Figure 6 is a flow chart of malicious continuous reset check in the present invention;
[0027] Figure 7 This is a flow chart of generating an intrusion detection balanced binary tree in this embodiment. DETAILED DESCRIPTION
[0028] The specific implementation of the present invention is described below in conjunction with the accompanying drawings so that those skilled in the art can better understand the present invention. It should be noted that in the following description, when the detailed description of known functions and designs may dilute the main content of the present invention, these descriptions will be omitted here.
[0029] Example
[0030] Figure 1 It is a flow chart of a specific implementation method of the intrusion detection method for the vehicle-mounted UDS protocol of the present invention.
[0031] like Figure 1 As shown, the specific steps of the intrusion detection method for the vehicle-mounted UDS protocol of the present invention include:
[0032] S101: Set intrusion detection rules:
[0033] In order to realize intrusion detection of the vehicle-mounted UDS protocol, the present invention sets intrusion detection rules for the vehicle-mounted UDS protocol, including illegal diagnosis request inspection rules, illegal diagnosis response inspection rules, diagnosis request legitimacy inspection rules, violent request authentication inspection rules, DTC active upload inspection rules, and malicious continuous reset inspection rules. The above intrusion detection rules are described in detail below.
[0034] The illegal diagnostic request check rule presets the SID (Security Identify) whitelist according to actual needs, and checks and matches the SID in the request data (Request) sent by the diagnostic party (Tester) to the ECU (Electronic Control Unit) with the preset SID whitelist in the rule. If a SID not defined in the whitelist appears, an exception is reported, otherwise the request data is processed normally.
[0035] Figure 2 FIG. 4 is an example flow chart of checking illegal diagnostic requests in this embodiment. Figure 2 As shown, the SIDs in the whitelist are defined as 10, 11, 23, 24, 27, 28, 3E, and 85. If the diagnostic party sends 11 01 to request the ECU to simulate the KL30 restart, by comparing the SIDs in the whitelist, SID11 is in the preset whitelist, then the ECU executes the command after checking. If the diagnostic instrument sends 22F187 to read the ECU part number, by comparing the SIDs in the whitelist, SID22 is not in the preset whitelist, then it is considered that an intrusion is detected and the abnormality will be reported.
[0036] The illegal diagnosis response check rule is similar to the previous rule. A whitelist is preset as needed, and the response ID is matched with the preset response ID in the rule. If an undefined response ID appears, an exception is reported, otherwise the request data is processed normally.
[0037] The diagnostic request legitimacy check rule sets the requirements for SID, field range number (Num), field position (Position), field format (Format), reference value relationship (Relation), and reference value (Value) in the diagnostic request data according to actual needs, and checks whether a certain field range of the request data meets the requirements. If it does not meet the requirements, an exception is reported, otherwise the request data is processed normally. This rule is a more flexible check rule, and the range limit of a certain field of the diagnostic service can be arbitrarily set.
[0038] Assume that for the diagnostic session control request 0x10, the request data of this service is fixed to 2 bytes, the first byte is the SID, and the lower 7 bits of the second byte are the sub-function, which is used to indicate the session that the ECU will enter. The range of sessions defined in the vehicle UDS protocol is 0x00-0x7F. Commonly used sessions are 0x01, 0x02, 0x03, and 0x04, and the rest are reserved bits or customized. Assume that the rules in this embodiment only allow the four sessions with sessions of 01, 02, 03, and 04 to pass, and the sessions in the rest range are not allowed. If they appear, it is considered that an intrusion is detected and an exception needs to be reported. For this, the rule parameters can be set to limit the detection object to the diagnostic session control request 0x10, and the session is the front-closed and rear-closed interval from 01 to 04. Only sessions 01, 02, 03, and 04 are allowed to pass the detection. If other sessions appear, it is considered that an intrusion has occurred and an exception will be reported. The rule can be set to check the session range of the session request through the diagnostic request legitimacy check.
[0039] The brute force request authentication check rule sets the number threshold and minimum interval time (MinInterval) of the permission acquisition request per unit time length (Cycle) according to actual needs. If the number of permission acquisition requests per unit time length exceeds the number threshold, or the interval time between two permission acquisition requests is less than the minimum interval time, an exception is reported, otherwise the request data is processed normally.
[0040] Some ECUs have some diagnostic services with a relatively high security level. Before executing such services, you need to execute the Security Access diagnostic command to perform an identity authentication and permission acquisition process. Figure 3 This is a flowchart of obtaining permissions. Figure 3 As shown, the diagnostic party (Tester) requests Seed from ECU and sends request instruction 27 05. After ECU determines that SID is correct, it responds to command 67 05 01 01 01 and sends Seed (01 01 01) to the diagnostic party. After receiving Seed, the diagnostic party sends Key (01 02 03) to ECU, 27 06 02 0304, and ECU verifies successfully and sends 67 06. At this time, a permission is obtained successfully. After at least MinInterval time, the diagnostic party requests a higher permission from ECU again 27 07. ECU responds to command 67 07 060606, and the diagnostic instrument sends Key 27 08 07 08 09. ECU verifies successfully and sends 67 08. Figure 3 It can be seen that there are a total of 2 permission request processes in a unit of time, and the shortest time interval between the two requests is MinInterval. Figure 4FIG. 4 is an example flow chart of the violent request authentication check in this embodiment. Figure 4 As shown, if the time interval between two permission requests is too short, an intrusion detection anomaly is triggered; if the number of permission requests within a unit time length exceeds the threshold (Threshold) set by the rule, an intrusion detection anomaly is triggered.
[0041] The DTC active upload check rule is that if a diagnostic request is received to enable DTC active upload, an exception will be reported, otherwise the request data will be processed normally.
[0042] Figure 5 This is the flowchart uploaded by DTC. Figure 5 As shown, most of the diagnostic communication process is question-and-answer style, with the diagnostic party sending a request and the ECU giving a response. The service with SID 0x86 is an exception. After the ECU receives this 0x86 service, when DTC is generated, the ECU will automatically report the generated DTC and related data environment. This function will always be in an enabled state until another service with SID 0x86 is used to shut down this behavior of the ECU. This command is generally used in the early development stage of the ECU and will not be used in the later use process. Therefore, the present invention is set to consider that an intrusion has occurred as long as the DTC active upload instruction is received, and the abnormality will be reported.
[0043] The malicious continuous reset check rule sets the threshold of the number of ECU reset request detections other than self-reset detection according to actual needs. If the number of ECU reset request detections other than self-reset detection forwarded by the gateway exceeds the threshold, an exception is reported, otherwise the request data is processed normally. Figure 6 Flowchart of malicious continuous reset check in the present invention. Figure 6 As shown in the figure, the instruction with SID 0x11 can reset and restart the ECU through a diagnostic request. By real-time detection and monitoring of diagnostic requests, the time and number of each reset request are recorded. If the number of resets exceeds the set threshold within the specified unit time, it means that there are high-frequency abnormal reset requests and a malicious continuous reset attack has occurred. At this time, the abnormality is reported. If it does not exceed the threshold, the ECU executes the instruction to reset. It should be noted that this rule only applies to the reset request detection forwarded by the gateway, and does not include the detection of its own reset.
[0044] S102: Configure intrusion detection rules for the subnet:
[0045] For each subnet in the in-vehicle CAN bus network, several intrusion detection rules are set for the ECU according to actual needs. Each rule is identified by the CAN ID of the ECU, and then the intrusion detection rules of all subnets are saved.
[0046] In this embodiment, in order to enable efficient search during subsequent intrusion detection, a balanced binary tree is used as the data structure for storing intrusion detection rules, that is, a balanced binary tree is generated for each subnet in the in-vehicle CAN bus network, and the nodes of the balanced binary tree are the CANIDs of the ECUs in the subnet. Then, each intrusion detection rule of the subnet is read in turn and placed in the intrusion detection rule set of the corresponding node in the balanced binary tree, thereby obtaining an intrusion detection balanced binary tree and storing it.
[0047] Figure 7 : is a flow chart of generating an intrusion detection balanced binary tree in this embodiment. Figure 7 As shown, in this embodiment, a balanced binary tree is first generated for each subnet, and then the rule file header is loaded, and each rule is read in turn. The file integrity check is first performed. After the check is successful, the rules are parsed one by one starting from the network segment 0. After taking out a rule, the rule is added to the AVL tree according to the CANID. After all the rules of the network segment are read, if there are multiple network segments, the next network segment is switched to continue parsing the rules until all the rules in all network segments are parsed. Since the CANID of the whole vehicle may be repeatedly allocated, but the CANID under different network segments will not be repeated, the CANID of different network segments can be mounted on different AVL trees, thereby improving the indexing efficiency of the CANID.
[0048] In addition, for the intrusion detection rule set of the nodes in the AVL tree, the intrusion detection rules are saved in a one-way linked list structure, thereby improving the average rule retrieval efficiency.
[0049] S103: Intrusion Detection:
[0050] After configuring the intrusion detection rules, you can perform intrusion detection based on these rules. The specific methods are as follows:
[0051] When the diagnostic direction sends request data to the ECU, the request data is cached in the cache area of the subnet to which the ECU belongs. Whenever the intrusion detection cycle arrives, the request data of each subnet is subjected to intrusion detection in turn using the following method: the request data is read from the cache area of the current subnet, and then all intrusion detection rules of the ECU corresponding to the request data are retrieved and read, and the request data is matched and detected using each intrusion detection rule in turn. After all request data of the current subnet have been detected, jump to the next subnet until all currently cached request data have been detected.
[0052] Although the above describes the illustrative specific embodiments of the present invention to facilitate those skilled in the art to understand the present invention, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art, as long as various changes are within the spirit and scope of the present invention as defined and determined by the attached claims, these changes are obvious, and all inventions and creations using the concept of the present invention are protected.
Claims
1. An intrusion detection method for a vehicle-mounted UDS protocol, characterized in that: The following steps are involved: S1: Set intrusion detection rules for the vehicle UDS protocol, including illegal diagnostic request check rules, illegal diagnostic response check rules, diagnostic request legitimacy check rules, violent request authentication check rules, DTC active upload check rules, and malicious continuous reset check rules, among which: The illegal diagnostic request check rule presets the SID whitelist according to actual needs, checks and matches the SID in the request data sent by the diagnostic direction to the ECU with the preset SID whitelist in the rule. If a SID not defined in the whitelist appears, an exception is reported, otherwise the request data is processed normally; The illegal diagnosis response check rule presets a response ID whitelist according to actual needs, matches the response ID in the diagnosis request with the preset response ID whitelist in the rule, and reports an exception if an undefined response ID appears, otherwise the request data is processed normally; The diagnostic request validity check rules set the requirements for SID, field range number, field position, field format, reference value relationship, and reference value in the diagnostic request data according to actual needs, and check whether a certain field range of the request data meets the requirements. If it does not meet the requirements, an exception is reported, otherwise the request data is processed normally; The brute force request authentication check rule sets the number threshold and minimum interval time of permission acquisition requests per unit time length according to actual needs. If the number of permission acquisition requests per unit time length exceeds the number threshold, or the interval time between two permission acquisition requests is less than the minimum interval time, an exception is reported. Otherwise, the request data is processed normally. The DTC active upload check rule is that if a diagnostic request is received to enable DTC active upload, an exception will be reported, otherwise the request data will be processed normally; Malicious continuous reset check rules set the ECU reset request detection number threshold other than self-reset detection according to actual needs. If the number of ECU reset request detections other than self-reset detection forwarded by the gateway exceeds the threshold, an exception is reported, otherwise the request data is processed normally; S2: For each subnet in the in-vehicle CAN bus network, set several intrusion detection rules for the ECU therein according to actual needs. Each rule is identified by the CAN ID of the ECU, and then the intrusion detection rules of all subnets are saved; S3: When the diagnostic direction sends request data to the ECU, the request data is cached in the cache area of the subnet to which the ECU belongs. Whenever the intrusion detection cycle arrives, the request data of each subnet is subjected to intrusion detection in turn using the following method: the request data is read from the cache area of the current subnet, and then all intrusion detection rules of the ECU corresponding to the request data are retrieved and read, and the request data is matched and detected using each intrusion detection rule in turn. After all request data of the current subnet are detected, jump to the next subnet until all currently cached request data are detected.
2. The intrusion detection method according to claim 1, characterized in that: The data structure for storing the intrusion detection rules in step S2 adopts a balanced binary tree, that is, a balanced binary tree is generated for each subnet in the in-vehicle CAN bus network, and the nodes of the balanced binary tree are the CANIDs of the ECUs in the subnet. Then, each intrusion detection rule of the subnet is read in turn and put into the intrusion detection rule set of the corresponding node in the balanced binary tree, thereby obtaining an intrusion detection balanced binary tree and storing it.
3. The intrusion detection method according to claim 2, characterized in that: The intrusion detection rules in the intrusion detection rule set are stored in a one-way linked list structure.
Citation Information
Patent Citations
Detecting anomalies in fault code settings and enhancing service documents using analytical symptoms
CN102799171A
Ethernet intrusion detection method based on vehicle-mounted MCU
CN112788014A