Method for controlling the right of communication based on default bit

Abstract

The application relates to a CAN communication permission control method based on a default bit in the technical field of vehicle information security and vehicle internal CAN message communication security, and comprises the following steps: (1) diagnosis request input and message construction; (2) message analysis and security check processing; and (3) permission determination and access control. The application introduces a message level permission identification mechanism by redefining the original filling byte of a CAN message as a security check bit without changing the existing UDS diagnosis message structure based on ISO 14229 and the protocol compatibility, so that the pre-position legality check of a diagnosis request is realized.

Description

Technical Field

[0001] This invention relates to the field of vehicle information security and vehicle internal CAN message communication security technology, specifically to a CAN communication access control method based on a default bit. Background Technology

[0002] In the current UDS over CAN implementation based on ISO 14229, the ECU only identifies the length field, service identifier (SID), and service sub-function when parsing diagnostic messages. The remaining bytes are filled with default values ​​and do not participate in function determination or permission verification. Although this implementation meets the basic requirements of the standard, the lack of a legality and permission recognition mechanism in the default padding area of ​​the message allows attackers to construct legitimate SIDs and sub-functions and combine them with arbitrary padding data to perform high-frequency fuzz tests, thereby increasing the risk of false triggering, abnormal execution, or potential attacks. Summary of the Invention

[0003] In the current UDS over CAN implementation based on ISO 14229, the ECU only performs functional identification based on the length field, service identifier (SID), and service sub-functions when parsing diagnostic messages. The default padding area of ​​the message is not involved in legality verification or permission determination, resulting in a single dimension of message structure identification and insufficient granularity of access control. Under these circumstances, attackers can construct legitimate service codes and combine them with arbitrary padding data to perform fuzzing or message traversal attempts, thereby increasing the risk of accidentally triggering critical services, abnormal execution, or potential attacks. Therefore, the core technical problem that this invention needs to solve is: how to improve the permission identification capability and message legality determination strength of CAN diagnostic messages without changing the existing protocol framework and compatibility, and to involve the default padding area of ​​the message in security verification, thereby enhancing the access control capability of the diagnostic interface and reducing the risk of accidental modification and the possibility of malicious exploitation.

[0004] To mitigate the risk of misuse and unauthorized modification of diagnostic interfaces, it is recommended to introduce a specific byte pattern as an authorization factor in the default padding area of ​​CAN messages, and to add padding content validity verification logic on the ECU side. Messages that do not meet the agreed padding rules should be rejected before service execution. This measure does not change the protocol structure but enhances message recognition dimensions, increases attack complexity, and reduces the risk of erroneous function triggering caused by randomly or maliciously constructed messages. It represents a security enhancement requirement for existing diagnostic communication mechanisms.

[0005] To address the aforementioned technical problems, this invention provides a CAN communication access control method based on a default bit, comprising the following steps: (1) Diagnostic request input and message construction: The tester inputs the UDS diagnostic request through the diagnostic tool or host computer, and generates CAN message data that conforms to ISO14229 accordingly; (2) Message parsing and security verification processing: After receiving the CAN message, the vehicle unit or ECU performs parsing and security verification processing; (3) Permission determination and access control: Based on the verification result of step (2), the following control logic is executed: When the verification passes: The diagnostic request was determined to have legitimate access rights. Allow entry into the corresponding diagnostic service processing flow; Perform the corresponding function operation; When the verification fails: The request was determined to be illegal or unauthorized access. Refuse to perform the corresponding diagnostic service; Return an error response or discard the message directly; Then return the process to step (1) and wait for new request input.

[0006] Further, in step (1), the CAN message includes a length field, service identifier, sub-function parameters and a padding byte area; the padding byte area is filled with a security verification code according to a preset rule and sent to the vehicle unit or target ECU along with the diagnostic request.

[0007] Furthermore, in step (2), the CAN message parsing and security verification processing methods are as follows: Perform integrity reception and basic format verification on messages; Parse the message length field according to ISO-TP rules and extract the valid data area; Identify the service identifier and sub-function parameters to determine the target diagnostic service type; Locate and extract the padding byte region in the message; The extracted padding bytes are used as a security verification field and compared with the authorization code pre-stored inside the vehicle's infotainment system. The authorization code can be pre-stored in the ECU's secure storage area and supports an update mechanism.

[0008] Furthermore, in step (3), an abnormal access restriction mechanism is introduced: Count the number of consecutive verification failures; When the number of verification failures exceeds the preset threshold: Suspend or block access to subsequent diagnostic requests; It can enter a locked state or a delayed response state; Access can only be restored after the preset recovery conditions are met.

[0009] The beneficial effects of this invention are as follows: (1) Reconstruction and innovation of the fill field function Without changing the original UDS message structure based on ISO 14229, the CAN message padding bytes, which were traditionally only used for alignment, are redefined as security check fields, thereby realizing the functional reconstruction and value enhancement of the "invalid field".

[0010] (2) Innovation of message-level permission identification mechanism Unlike access control methods that rely solely on session state or SecurityAccess, this invention introduces access control factors at the message level to achieve "message-level access control" and improve the granularity of access control.

[0011] (3) Protocol-compatible security enhancement design Security enhancement is achieved by strengthening the semantics of existing fields without adding new service numbers, expanding data segments, or changing the ISO standard structure, ensuring compatibility with existing diagnostic tools and protocol stacks.

[0012] (4) Lightweight safety reinforcement mechanism Permission recognition is achieved by using a fixed or preset check byte pattern, without introducing complex encryption or additional communication interactions. This results in low system resource consumption and is suitable for resource-constrained ECU scenarios.

[0013] (5) Improved resistance to fuzz testing Expanding the dimensions of message legitimacy determination increases the complexity for attackers to construct valid messages, raising the threshold for identification by random messages or automated scanning tools.

[0014] (6) Pre-positioned security filtering mechanism By moving the security verification process forward to before service execution, we can achieve "pre-execution interception," preventing illegal requests from entering specific functional processing logic and reducing the risk of abnormal execution from the architectural level.

[0015] (7) Attack surface contraction design concept By enhancing message identification features, the space of messages that can be effectively triggered by the system is reduced, thus achieving proactive shrinking of the attack surface of the diagnostic interface.

[0016] (8) Scalable permission hierarchy design capability Security check bits can differentiate between multiple levels of permissions based on different fixed codes, providing design space for subsequent expansion of hierarchical diagnostic access control. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the CAN communication permission control method based on the default bit of the present invention. Figure 2 This is a schematic diagram of the CAN communication permission control method based on the default bit of the present invention. Detailed Implementation

[0018] The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, so that the advantages and features of the present invention can be more easily understood by those skilled in the art, thereby providing a clearer and more explicit definition of the scope of protection of the present invention.

[0019] like Figure 1 , Figure 2 The CAN communication access control method based on default bits, as shown, includes the following steps: (1) Diagnostic request input and message construction: The tester inputs the UDS diagnostic request through the diagnostic tool or host computer, and generates CAN message data that conforms to ISO14229 accordingly; The CAN message includes at least a length field (ISO-TP format), a service identifier (SID), sub-function parameters, and a padding byte area; The filling byte area is filled with security verification code (such as a fixed byte sequence or a verification value generated based on an algorithm) according to a preset rule, and sent to the vehicle system or target ECU along with the diagnostic request.

[0020] (2) Message parsing and security verification: After receiving the CAN message, the vehicle unit or ECU performs parsing and security verification, and executes the following processing flow in sequence: Perform integrity reception and basic format verification on messages; Parse the message length field according to ISO-TP rules and extract the valid data area; Identify the service identifier (SID) and sub-function parameters to determine the target diagnostic service type; Locate and extract the padding byte region in the message; The extracted padding bytes are used as a security verification field and compared with the authorization code pre-stored inside the vehicle's infotainment system. The authorization code can be pre-stored in the ECU's secure storage area and supports an update mechanism.

[0021] (3) Permission determination and access control: Based on the verification result of step (2), the following control logic is executed: When the verification passes: The diagnostic request was determined to have legitimate access rights. Allow entry into the corresponding diagnostic service processing flow; Perform corresponding functional operations (such as session switching, data reading, routine control, etc.); When the verification fails: The request was determined to be illegal or unauthorized access. Refuse to perform the corresponding diagnostic service; Return an error response or discard the message directly; Then return the process to step (1) and wait for new request input; Introduce an abnormal access restriction mechanism: Count the number of consecutive verification failures; When the number of verification failures exceeds a preset threshold (e.g., 3 times): Suspend or block access to subsequent diagnostic requests; It can enter a locked state or a delayed response state; Access will be restored only after the preset recovery conditions are met (such as system restart, timeout recovery, or re-authentication).

[0022] The CAN communication permission control method based on default bits of this invention maintains the basic format of existing UDS diagnostic messages based on ISO 14229 unchanged, without modifying the Service Identifier (SID), sub-function definitions, or standard data structures, and does not affect the compatibility of existing diagnostic protocol frameworks and communication mechanisms. Specifically, after the vehicle's infotainment system completes length recognition, it defines the byte area that was originally only used as default padding as a security check bit. The padding area is upgraded from a passive placeholder field to a valid field participating in message validity determination. The security check bit uses a custom fixed byte pattern or a preset code as the permission identification identifier. When the vehicle's ECU performs security recognition, it verifies the validity of the security check bit. The security check field in the message must be compared with the pre-stored authorization code in the vehicle. Only when the verification result matches can the next stage of functional processing proceed.

[0023] The method flow of the present invention will be described in detail below with reference to specific embodiments: Taking the diagnostic device requesting entry into an extended session (0x10 03) as an example, the method flow of the present invention will be described.

[0024] Testers constructed and sent a single-frame CAN message using diagnostic tools: 02 10 03 A5 A5 A5 A5 A5 The first three bytes are the valid data of the standard UDS message based on ISO 14229, and the subsequent padding bytes are the security verification fields defined in this invention.

[0025] Upon receiving this message, the vehicle's infotainment system or ECU will process it according to the following procedure: (1) Perform integrity verification on the received CAN message and parse the length field based on ISO-TP rules to determine the valid data length; (2) Identify the service identifier (0x10) and sub-function (0x03) to determine that the request is a diagnostic request to enter the extended session; (3) Extract the remaining padding byte region (A5 A5 A5 A5 A5) and use it as a security verification field; (4) Compare the security verification field with the authorization code pre-stored inside the ECU byte by byte; (5) When the comparison results match, the request is deemed a valid request, allowing the session switching operation corresponding to service 0x10 to be executed, and a positive response message is returned, for example: 50 03 00 32 01 F4 (6) When the comparison results are inconsistent, for example, when the following message is received: 02 10 03 00 00 00 00 00 If the request is deemed illegal, the ECU will refuse to perform the session switching operation and will return a negative response message (such as 7F10 XX) or discard the message directly. (7) At the same time, the ECU counts the number of consecutive verification failures. When the number of failures exceeds a preset threshold (e.g., 3 times), it enters an access restriction state. In this state, subsequent diagnostic requests are rejected until the preset recovery conditions are met and the restriction is lifted.

[0026] This invention, without altering the existing UDS diagnostic message structure and protocol compatibility based on ISO 14229, redefines the original padding bytes of the CAN message as security check bits and introduces a message-level permission recognition mechanism to achieve pre-emptive legality verification of diagnostic requests. Its beneficial effects are: first, it enhances the message recognition dimension and strengthens the granularity of access control for the diagnostic interface; second, it increases the attack complexity of maliciously constructed messages, improving resistance to fuzzing and random scanning behaviors; third, by placing security verification before function execution, it prevents unauthorized requests from entering specific business logic, reducing the risk of false triggering and abnormal execution from an architectural perspective; fourth, it eliminates the need for complex encryption or additional communication interactions, resulting in low system implementation cost and minimal resource consumption, making it suitable for resource-constrained ECU scenarios; and fifth, it reserves design space for subsequent implementation of hierarchical permission control and extended security strategies, comprehensively improving the security and controllability of the diagnostic communication mechanism.

[0027] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape, principle and application direction of this application should be covered within the scope of protection of this application.

Claims

1. A CAN communication access control method based on a default bit, characterized in that, Includes the following steps: (1) Diagnostic request input and message construction: The tester inputs the UDS diagnostic request through the diagnostic tool or host computer, and generates CAN message data that conforms to ISO14229 accordingly; (2) Message parsing and security verification processing: After receiving the CAN message, the vehicle unit or ECU performs parsing and security verification processing; (3) Permission determination and access control: Based on the verification result of step (2), the following control logic is executed: When the verification passes: The diagnostic request was determined to have legitimate access rights. Allow entry into the corresponding diagnostic service processing flow; Perform the corresponding function operation; When the verification fails: The request was determined to be illegal or unauthorized access. Refuse to perform the corresponding diagnostic service; Return an error response or discard the message directly; Then return the process to step (1) and wait for new request input.

2. The CAN communication access control method based on the default bit according to claim 1, characterized in that, In step (1), the CAN message includes a length field, service identifier, sub-function parameters and padding byte area; the padding byte area is filled with security verification code according to preset rules and sent to the vehicle unit or target ECU along with the diagnostic request.

3. The CAN communication access control method based on the default bit according to claim 2, characterized in that, In step (2), the CAN message parsing and security verification processing methods are as follows: Perform integrity reception and basic format verification on messages; Parse the message length field according to ISO-TP rules and extract the valid data area; Identify the service identifier and sub-function parameters to determine the target diagnostic service type; Locate and extract the padding byte region in the message; The extracted padding bytes are used as a security verification field and compared with the authorization code pre-stored inside the vehicle's infotainment system. The authorization code can be pre-stored in the ECU's secure storage area and supports an update mechanism.

4. The CAN communication access control method based on the default bit according to claim 3, characterized in that, In step (3), an abnormal access restriction mechanism is introduced: Count the number of consecutive verification failures; When the number of verification failures exceeds the preset threshold: Suspend or block access to subsequent diagnostic requests; It can enter a locked state or a delayed response state; Access can only be restored after the preset recovery conditions are met.

Images